Article en édito

[Philippe-M]

Tout comme il est possible de définir un article s'affichant sur la page d'accueil il pourrait être intéressant d'avoir une catégorie "Edito" dans l'édition d'article qui permettrais d'avoir toutes les fonctionnalités de la rédaction d'un article afin de pouvoir créer un bloc (côté public) pour la "description" du site.

http://forum.pluxml.org/viewtopic.php?id=6061

[jerrywham]

Il y a un article à ce sujet sur Pluxopolis.net, il me semble.

[Philippe-M]

Oui jet 'ai testé mais c'est pas facile à intégrer de façon simple pour un utilisateur lambda car il faut aller modifier le thème.

[jerrywham]

Oui, mais une fois le thème modifié, on n'a pas à revenir dessus. L'administrateur du site peut le faire et expliquer ensuite la procédure aux autres utilisateurs qui n'auront pas à modifier le thème.

[jerrywham]

Pour mémoire, l'article se trouve là : http://pluxopolis.net/article6/mettre-en-place-un-edito

[Philippe-M]

Ok, mais nous avons une partie de la communauté qui n'est pas admin, pas dev, tout simplement utilisateur. L'installation de PluXml est à la portée de tous et encore plus depuis qu'il est possible de l'installer depuis un simple fichier.

L'édito me parait être une fonction de base dans un cms. C'est un moyen de présenter le site au visiteur. Il peut se trouver dans une sidebar, au-dessus des articles. En tout cas visible au premier coups d'oeil du visiteur et non perdu sur une page statique "A propos".

[jerrywham]

Dans ces conditions (si l'on ne doit pas mettre les mains dans le code), c'est aux thèmes à s'adapter. Si l'on veut un édito, on choisit un thème qui permet de l'afficher. Pluxml fournit déjà tous les outils pour pouvoir le faire facilement.

[Philippe-M]

Je vois pas à quel endroit de PluXml il est possible de définir un édito ? Si c'est l'article "page d'accueil" pour moi c'est une notion différente, puisqu'une fois un article définit en page d'accueil tout les autres articles disparaissent.

[jerrywham]

Tu n'as pas lu l'article de Stéphane...

[Philippe-M]

Si si j'ai même été le relire à l'instant et il faut bien éditer un fichier du thème pour y faire des modifications de code qui sont totalement incompréhensible pour un utilisateur.

[bazooka07]

Il faudrait que cela soit intégré en standard dans PluXml. Je l'avais fait avec la version 5.5 et cela marchait très bien. Plutôt que d'édito, je préfère parler articles épinglés comme dans les forums de discussion. Le principe est de créer une catégorie spéciale pin avec un ID=999 puisque c'est le dernier identifiant permis pour les catégories, au même titre qu'il existe une catégorie home avec id=000. Il suffit ensuite de modifier la routine de tri des articles pour que tous les articles de cette catégorie soient toujours en début de liste. On peut éventuellement ajouter une entrée dans les paramètres généraux pour limiter le nombre d'articles affichés pour cette catégorie. Au delà de cette limite, l'article reprend un comportement normal. Je veux bien reporter cela sur la version 5.6 mais j'ai pas mal de pull-requests en attente.

L'intérêt pour moi était de pourquoi annoncer longtemps à l'avance des événements en haut de page sans interrompre la publication d'articles sans avoir d'intact sur le thème utilisé.

[bazooka07]

J'ai modifié PluXml sur un site pour gérer les articles épinglés ou éditos. Au final, l'ID de la catégorie pour ces articles sera "pin", comme il existe "home" déjà. On peut définir dans les paramètres d'affichage le nombre d'articles épinglés à afficher. Evidemment possibilité de filtrer ces articles dans pa page index de l'administration

Le plus gros souci a été de formater correctement les expressions régulières mal ficelées pour filtrer les articles. C'est un problème récurrent à chaque version dePluXml.

Si vous voulez tester, c'est sur la branche pin-article de mon dépôt Github : git clone https://github.com/bazooka07/PluXml.git -b pin-article

Je suis parti sur le dernier pull-request validé #275 ( 4mois )

[Philippe-M]

J'avais commencé à travailler sur la modification mais je vois que tu a été plus rapide que moi ;)

Je test ça ce week-end.

[bazooka07]

Oups, j'avais oublié les flux RSS et sitemap.php dans le 1er push. Plus 2 à 3 erreurs typo

Le plus gros du boulot est de ressuivre toutes les expressions régulières qui servent à filtrer les articles. Après cela, c'est facile, hormis rajouter une entrée dans article.php, index.php, parametres_affichage.php

dans la foulée tu peux tester aussi la branche urlrewriting-1712 pour avoir des urls plus sympas.

[bazooka07]

Soyons fous En reprenant le principe du code "pin" et après le gros nettoyage de des expressions régulières pour filtrer les articles, on peut rajouter d'autres catégories spéciales comme adm, mng, mod, edt, wrt, sub, pour limiter l'affichage d'articles aux administrateurs, managers, modérateurs, editeurs, rédacteurs et abonnés. Il faudrait rajouter un profil subscriber pour identifier les abonnés du site sans autre droit que de celui de s'identifier. Mais cela je ne peux le faire qu'après avoir merger la branche pin-article avec la branche urlrewriting-1712. Git n'arrive pas à "merger" tout automatiquement pin-article dans urlrewriting-1712. Je suis obligé de remettre en cause de façon importante les regex de PluXml.

[bazooka07]

Démo online ici https://www.echecs-annonay.fr/ un article rédigé le 4 avril passe devant tout le monde, une fois épinglé. Et joli réécriture des URLs sans numéro d'article ou de page statique

[Philippe-M]

Salut, j'ai enfin pris le temps de tester ta version pin-article et pour le moment tout est ok. Il est clair que tu a pas mal triturer les regex du moteur ;)

Merci pour ton dev

[bazooka07]

Mon sentiment est que les regex sont mal maitrisées dans PluXml depuis le début. Beaucoup de boulot pour remettre de l'ordre.

[Philippe-M]

De ce que j'ai vue des regex elles sont identiques, est-ce qu'il ne serait pas intéressant de définir des constantes pour chaque regex pour simplifier la maintenance ?

[bazooka07]

Si tu as un exemple, donne-moi le. A priori, il ne doit pas avoir trop de doublons.

Ce qui serait intéressant, c'est une fonction qui calcule la regex à partir du contexte.

J'ai cela dans la méthode plxMotor:prechauffage() ou la regex pour filtrer les articles est calculé à partir d'un tableau avec des entrées pour l'id_article, les catégories, l'auteur, la date, l'url de l'article. C'est nettement plus clair par rapport à la fonction initial

[haruka-7]

Je ne suis pas d'avis d'intégrer et de maintenir cette fonctionnalité en natif dans PluXml, car je ne suis pas convaincu que se soit une feature indispensable à une majorité d'utilisateurs. De plus, je suis d'accord sur le fait que ça se gère très bien via la modification d'un thème (l'article de Stéphane http://pluxopolis.net/article6/mettre-en-place-un-edito).

[bazooka07]

La modification du thême préconisée sur Pluxopolis n'est pas à la portée du premier venu. Elle nécessite de maitriser un minimum PHP. Je ne parle même pas des erreurs de frappe qui plantent tout. Et il faut pointer de la catégorie de l'édito.

Pour être accessible au plus grand nombre, cette feature doit être intégrée nattivement à PluXml. et ne pas exiger de connaissance particulière en PHP.

D'autant que le job est déjà fait.

Un peu surpris par ton jugement !

[Philippe-M]

Je suis d'accord avec @bazooka07 , intrégré sa modification la rend accessible à tous et non aux bricoleurs/intégrateurs/dev.

Pour moi, il y a un choix à faire pour le futur de PluXml :

• reste-t'il un moteur de blog ?
• évolue-t'il vers un framework pour créer des sites ?

Dans la 1ere vue effectivement la modification n'est pas nécessaire car peu/pas utilisé. Dans la seconde vue, elle est nécessaire car il est courant d'avoir une "intro" pour présenter le site.

Reste à savoir si PluXml reste un moteur de blog ou bien si il doit évoluer vers un framework de création site et du coups gagner en fonctionnalitées ?

[bazooka07]

PluXml finira comme Wordpress ! Au départ, c'est un simple moteur de blog. Puis des esprits pernicieux en ont l'usage d'un framework pour créer des sites. Et cela se passe très bien. Même si dans bien des cas un Jekyll or un Hugo seraient plus appropriés Donc, si on peut éviter de se faire gazer au milieu de l'usine Wordpress, cela serait aussi bien. Suffit juste d'avoir de bons thèmes

[haruka-7]

Je reviens au sujet de l'édito (mais on peut débattre une énième fois de l'avenir de PluXml sur le forum, si vous le souhaitez). Est-ce qu'on pourrait pas s’inspirer de ce qui est fait pour le paramètre "Emplacement : Page d'accueil" (qui n'est pas géré comme une catégorie), pour créer un nouvel emplacement du type "Mise en avant" ?

[Pluxopolis]

Pour éviter d'impacter le core de PluXml avec cette fonctionnalité (qui n’intéressera pas tout le monde), regardez ce qu'il est possible de faire avec les modules, une approche que j'avais envisagé pour diffuser des "plugins" officiels (basé sur le même principe que le plugins): voir la branche dédiée dans github

[bazooka07]

@P3ter, Je suppose que tu parles de "l'emplacement page d'accueil" situé dans la page d'édition d'un article. Stéphane a expliqué, il y a fort longtemps, comment était structuré le nom d'un fichier article dans le lien ci-après : http://pluxopolis.net/article10/comprendre-le-nom-des-fichiers-xml-des-articles Pour être plus synthéthique, ces noms de fichiers sont validées par l'expression régulière suivante :

@^_?\d{4}\.(?:home,|draft,|\d{3},)*\d{3}(?:,\d{3}|,draft)*\.\d{3}\.\d{12}\.[\w-]+\.xml$@

ces noms sont découpés en blocs séparés par un point.

• id de l'article
• une ou plusieurs catégories avec éventuellement "home" en premier pour la page d'accueil. Si aucune catégorie n'a été précisée dans l'édition de l'article, ce sera pas défaut "000" ( catégorie nulle)
• id de l'auteur
• date de publication au format base de données YYYYmmddHHMM
• url de l'article
• extension du fichier toujours égal à "xml"

Ceci étant compris, il est facile de rajouter une catégorie spéciale "pin", au même titre que "home" ou "draft", pour les éditos ou, plus simplement, les articles épinglés (pin)

@^_?\d{4}\.(?:home,|draft,|pin,|\d{3},)*\d{3}(?:,\d{3}|,pin|,draft)*\.\d{3}\.\d{12}\.[\w-]+\.xml$@

Il suffit ensuite de prendre en compte cette catégorie dans le tri des articles pour afficher les articles correspondants en premiers. Modif qui fait déjà l'objet d'un pull-request.

Le gros souci c'est que les expressions régulières sont écrites de façon très fantaisistes dans PluXml et qu'il faudrait d'abord remettre tout cela d'aplomb. Cela fait des années que je le dis !!! J'avais déjà proposé des modifs que j'avais fait avec PluXml 5.5 qui n'ont jamais été prises en compte. En conséquence, quand je suis passé à la version 5.6, avec un an de retard, j'ai dû recommencé tout le job.

Mais j'ai peur que le gap à franchir pour maitriser les expressions régulières soit trop élevé pour les auteurs/mainteneurs de PluXml. Et je vois qu'on va IMPOSER l'usage de plugins officiels sous forme de modules pour remédier à cela comme un "cataplasme sur une jambe de bois".

Et quand je vois le nombre de pull-requests qui s'accumulent, je me dis que améliorer PluXml va devenir de plus en plus difficile.

[bazooka07]

Cette fonctionnalité sera intégrée à la prochaine version de PluXml, a priori 5.9.0 ou plus Au titre qu'il existe la catégorie "home", il y aura la catégorie"pin" comme "épinglé" Tous les articles faisant partir de cette catégorie seront affichés en tête de liste en mode "home", "categorie" ou "tags".