commentaires sur PluXml 5.5
niqnutn
Member
Bonjour,
Voici quelques commentaires sur la dernière version de PluXml:
[list=*]
[*]un peu d'homogénité entre les labels articles / pages statiques (coté administration) : "Éditer | Visualiser" ou "Éditer Voir" [/*]
[*]édition des articles:[list=*]
[*]la multiplication des dates est incompréhensible (presque), on se croirait dans une gare avec les horaires de train. je pense que gérer ça dans un pugin aurait plus de sens, sinon il faut revoir l'interface. je ne pense pas qu'on retrouve la simplicité de PluXml là dedans. [/*]
[*]image d'accroche: j'ai bien compris que cette fonctionnalité soit demandé par de nombreux utilisateurs mais on alourdit l'interface pour quelque chose de superficiel. personnellement, je verrai encore ça comme un plugin.[/*]
[*]bouton "Publier | Mettre hors ligne" au mauvais endroit et à mettre loin du bouton enregistrer (je me suis déjà fait avoir). faire une liste déroulante pour ça et le placer à coté de "État" serait une meilleure idée. un avertissement (popup) comme pour supprimer serait pertinent.[/*]
[*]bouton "Supprimer" que j'aurai envie de mettre à l'écart pour éviter les erreurs[/*]
[*]une fonction corbeille pour les articles supprimés serait appréciable[/*]
[/list]
[/*]
[*]administration > thèmes: changer le label pour "Modifier les options d'affichage" pour quelque chose de plus intuitif "Modifier le thème"[/*]
[*]dans le menu d'administration, je pense que l'entrée "Nouvel article" pourrait intégrer la section "Article" (core/admin/index.php?) et ajouter simplement un bouton dans le menu supérieur pour créer un article.[/*]
[/list]
Ce n'est que mon avis et je ne souhaite pas critiqué le travail réalisé jusque là.
Je pense qu'il faut rester cohérent et quand je lis sur la page d'accueil "Simple et léger" et je crois que cette nouvelle version s'en écarte de plus en plus. De mon point de vue, il n'est pas souhaitable d'ajouter toutes les fonctions voulues par les développeurs ou les membres de la communauté (du moins, pas directement dans le core).
PluXml offre la possibilité d'ajouter des plugins et ça me semble le plus important. Ajouter des fonctionnalités via les plugins est essentiel et je crois qu'ajouter des plugins (officiels) comme pour l'image d'accroche, les dates de modifications ou une page de contact serait plus intéressant. Ces plugins auraient l'avantage d'être parfaitement compatible avec PluXml sans alourdir le fonctionnement de base.
Cela nécessite de prendre en compte / faire évoluer la structure des données mais aussi les différentes fonctions de PluXml pour que cela soit possible.
Évidemment, il faudrait les ajouter dans l'archive et donc disponible dés l'installation. Un gestionnaire de plugin permettant de télécharger directement depuis un dépôt serait également un progrès.
Avoir une roadmap officielle serait aussi intéressant. Connaître les évolutions futur du projet me semble logique vu la taille du projet.
J'espère que ce projet continuera dans la même direction et en gardant la même simplicité comme quand je l'ai découvert.
Voici quelques commentaires sur la dernière version de PluXml:
[list=*]
[*]un peu d'homogénité entre les labels articles / pages statiques (coté administration) : "Éditer | Visualiser" ou "Éditer Voir" [/*]
[*]édition des articles:[list=*]
[*]la multiplication des dates est incompréhensible (presque), on se croirait dans une gare avec les horaires de train. je pense que gérer ça dans un pugin aurait plus de sens, sinon il faut revoir l'interface. je ne pense pas qu'on retrouve la simplicité de PluXml là dedans. [/*]
[*]image d'accroche: j'ai bien compris que cette fonctionnalité soit demandé par de nombreux utilisateurs mais on alourdit l'interface pour quelque chose de superficiel. personnellement, je verrai encore ça comme un plugin.[/*]
[*]bouton "Publier | Mettre hors ligne" au mauvais endroit et à mettre loin du bouton enregistrer (je me suis déjà fait avoir). faire une liste déroulante pour ça et le placer à coté de "État" serait une meilleure idée. un avertissement (popup) comme pour supprimer serait pertinent.[/*]
[*]bouton "Supprimer" que j'aurai envie de mettre à l'écart pour éviter les erreurs[/*]
[*]une fonction corbeille pour les articles supprimés serait appréciable[/*]
[/list]
[/*]
[*]administration > thèmes: changer le label pour "Modifier les options d'affichage" pour quelque chose de plus intuitif "Modifier le thème"[/*]
[*]dans le menu d'administration, je pense que l'entrée "Nouvel article" pourrait intégrer la section "Article" (core/admin/index.php?) et ajouter simplement un bouton dans le menu supérieur pour créer un article.[/*]
[/list]
Ce n'est que mon avis et je ne souhaite pas critiqué le travail réalisé jusque là.
Je pense qu'il faut rester cohérent et quand je lis sur la page d'accueil "Simple et léger" et je crois que cette nouvelle version s'en écarte de plus en plus. De mon point de vue, il n'est pas souhaitable d'ajouter toutes les fonctions voulues par les développeurs ou les membres de la communauté (du moins, pas directement dans le core).
PluXml offre la possibilité d'ajouter des plugins et ça me semble le plus important. Ajouter des fonctionnalités via les plugins est essentiel et je crois qu'ajouter des plugins (officiels) comme pour l'image d'accroche, les dates de modifications ou une page de contact serait plus intéressant. Ces plugins auraient l'avantage d'être parfaitement compatible avec PluXml sans alourdir le fonctionnement de base.
Cela nécessite de prendre en compte / faire évoluer la structure des données mais aussi les différentes fonctions de PluXml pour que cela soit possible.
Évidemment, il faudrait les ajouter dans l'archive et donc disponible dés l'installation. Un gestionnaire de plugin permettant de télécharger directement depuis un dépôt serait également un progrès.
Avoir une roadmap officielle serait aussi intéressant. Connaître les évolutions futur du projet me semble logique vu la taille du projet.
J'espère que ce projet continuera dans la même direction et en gardant la même simplicité comme quand je l'ai découvert.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Les choses qui portent à confusion peuvent être expliquées si elles ne font pas toujours du sens à première vue. Les fonctions que tu juges superflues peuvent être ignorées sans rien briser. L'écran d'administration est soigneusement amélioré de version en version sans vouloir en faire une horreur comme Wordpress mais en lui donnant autant de force. On y est presque, je suis bien placé pour le dire puisque je tire mes thèmes des banques de Wordpress la plupart du temps.
Si tu ne veux pas voir certaines de ces fonctions, on pourra te montrer comment les retirer de ta vue, pour nous elles sont nécessaires et utilisées quotidiennement.
Les plugins, c'est bien (j'en ai créé).
Mais collectionner plus d'une dizaine de plugins pour avoir des fonctions assez basiques comme celles citées ne simplifie pas les choses, bien au contraire.
Après, tu peux toujours créer un plugin pour supprimer les éléments que tu ne désire pas voir dans l'interface de PluXml...
Quand j'ai lancé la première fois, la 5.5 j'ai pas vraiment compris l'utilité. Ensuite j'ai créé des articles et commentaires avec plxMyLoremIpsum et j'avais systématiquement des erreurs avec les dates (le plugin ne doit pas être à jour et les dates sont toutes obligatoires) donc impossible d'enregistrer les articles.
Quand à modifier l'interface d'administration, c'est un peu gros. Comment, j'aurai fait dans le cas précédent ?
Sur la manière de gérer les nouvelles fonctionnalités, j'ai donné mon avis et ça me parait être un bon compromis.
D'ici peu on aura, une page de contact, une recherche, les boutons de réseaux sociaux, un wysiwig, ... mais du coup, ça ressemblera plus à un wordpress qu'à PluXml.
D'ailleurs, je n'ai jamais demandé de retirer ces fonctionnalités. Au mieux, j'aimerai pouvoir les avoir à disposition de manière optionnelle sous forme de plugin (dans la mesure ou c'est possible).
D'ailleurs, pour en revenir aux dates, elles ne sont pas gérées dans le thème par défaut. C'est bien la preuve que ça n'est utile que pour certains utilisateurs et loin d'être indispensable.
Après, il faut faire la différence entre ce qui est voulu et ce que l'on obtient comme résultat final. L'évolution et l'ajout de nouvelle fonctionnalités peuvent paraître intéressantes mais face à la réalité, on se rend compte que ça n'est pas aussi parfait qu'on aurait pu le souhaiter.
C'est plus une réflexion sur l'évolution du projet qu'une critique à un instant donné.
Je pensai que toutes les discussions autour des éditeurs avaient permis d'expliquer pourquoi rien n'était imposé. C'est d'ailleurs pour moi le meilleur exemple, on a le choix entre différentes éditeurs pour contenter absolument tout le monde.
Je ne demanderai pas d'enlever les fonctions qui ne me sont pas utiles. J'explique une manière de faire évoluer PluXml tout en contentant le maximum et en gardant l'image que j'avais de ce projet qui se voulait simplet et léger.
Prendre l'argument que ces fonctionnalités ont été demandées et applaudis, c'est pas vraiment un argument. Si je demande une coloration syntaxique pour le code dans PluXml, je pense que personne ira dire que c'est mal. Pour autant, ça n'est pas intégré dans PluXml et j'ai plusieurs plugins à disposition et ça me convient parfaitement comme beaucoup d'autres.
Pour faire simple, les fonctionnalités cosmétiques ou susceptibles d'intéresser qu'une partie des utilisateurs devraient plutôt être gérer comme des plugins. Évidemment, il faut que cela soit possible et gérer avec les hook ou la structure des données dans le cas des dates et des images d'accroche. Si on prend l'exemple des commentaires, c'est pas du tout la même chose. L'évolution de PluXml est naturelle et c'est du bon travail qui peut difficilement être remis en cause.
D'ailleurs, introduire les nouveautés via des plugins permettrait de mieux savoir si c'est utile et utilisé et éviter potentiellement certains bugs.
Reste plus qu'un gestionnaire de plugin un peu plus avancé (capable d'installer et de faire les mises à jour) pour vraiment faire un pas en avant.
En quoi, avoir des plugins ne simplifie pas les choses ?
Suggérer de tout mettre en plugins et ensuite indiquer du même souffle que des plugins ont causé des problèmes en tentant de les utiliser, c'en est tout de même un peu rigolo. La mise à jour des plugins viendra bien quand on en fait mention à son auteur, il faut pas désespérer. Un plugin comme LoremIpsum existe pour des fins de développement, c'est pas comme si on pensait ouvrir un site avec du texte bidon.
Remettre des fonctions sous forme de plugin, c'est exactement la définition de les retirer. Le core se voit ajouter des fonctions qui finissent par faire un genre d'unanimité à force de conversations parfois houleuses. Si on ajoutait tous les plugins qui existent dans le core, il deviendrait un mastodonte ingérable, si on retirait toutes les fonctions, les nouveaux ne sauraient pas par où commencer. Je passe des heures chaque semaine à interpréter des thèmes téléchargeables dans toutes les grandes plateformes, je suis bien placé pour indiquer ce qui compose la liste des "must" qui se retrouvent presque partout. Les besoins marginaux sont alors très bien remplis par les plugins, PluXml n'y fait pas exception.
Mes thèmes peuvent être utilisés immédiatement au téléchargement, les améliorations de la version 5.5 en sont la principale raison. Les images d'accroche peuvent être ignorées si on désire un site plein texte qui rend heureux ce genre de public. Désolé mais le web a fait du chemin depuis, une image rattachée à un article est un champ extrêmement commun qui fait entrer PluXml dans le 21e siècle. J'utilise cette fonction à toutes les pages, point à la ligne.
Tout ceci étant dit, tu seras le bienvenu lors des discussions pour la version prochaine de PluXml. Les opinions sur les fonctions qui devraient être ajoutées, améliorées (et pourquoi pas retirées) feront partie des conversations, c'est certain. C'est très sain de se demander pourquoi quelque chose est là, les pour et les contre pourront alors se prononcer.
Prenons mon dernier plugin par exemple : SuggestAvecImage
J'utilise l'image d'accroche de PluXml pour afficher des suggestions d'articles avec leurs images d'accroche. J'utilise également cette image d'accroche dans mon thème, comme bien d'autres.
J'aurais pu utiliser le Plugin Vignette, mais aussi spxData ou peut-être d'autres encore.
J'utilise aussi la date de modification pour suggérer en priorité des articles récents. Selon moi, c'est mieux que la date de publication, car un article modifié récemment reste d'actualité, même s'il a été publié il y a longtemps.
J'aurais pû créer un champ DateModif dans les articles et ajouter une date de modification dans l'édition des articles par plugin, mais si un autre plugin a besoin aussi de la date de modification, il lui faudrait également ajouter une date de modification, donc on aurait 2 dates de modifications dans l'édition des articles !
Il est vrai en revanche que ces éléments pourraient être affichés ou non selon une option d'affichage dans PluXml...
Cet air très connu est chanté sur toutes les plateformes, et on ne parle même pas des conflits entre plugins. Quand le core évolue, c'est un stress ajouté mais avouons que les créateurs de plugins de PluXml sont très généreux de leur temps quand ce grand passage doit se faire. Rares sont les cas où un pauvre utilisateur doit rester "prisonnier" d'une version antérieure pour cause de plugin désuet. Stéphane donne des mois pour travailler les petites différences et prévoir sa mise à jour en conséquence.
De mon côté, je prêche souvent pour l'inclusion de certaines fonctions dans le core, mais c'est parce qu'un thème moderne demande une intégration visuelle dans ses propres feuilles de style. Demander de faire ça à un nouveau, c'est presque suicidaire.
Grattons-nous la tête pour offrir une flexibilité sans encombrement, on arrivera bien à quelque chose.
Ce n'est certainement pas le plugin à mettre à jour le plus important.
On sait tous que les plugins seront presque toujours mis à jour uniquement par le développeur mais ça peut changer.
Il y a aussi une chose importante, il y a bien une section plugin officiel. Si on gère justement certaines fonctions correctement et qu'on s'assure de la stabilité à chaque mise à jour on éviterait des pb. Il faut donc bien faire le choix de plugins officiels qui doivent être testés.
Pour les conflits entre plugins, ça serait éludé si on prend le parti de ne maintenir que ceux qui sont officiels.
Pour le pb soulever par Suricat à propos des plugins sur l'image d'accroche, c'est exactement ce que j'essaie d'expliquer.
Il faut un moment que le développement prenne en compte cette problématique et propose quelque chose.
Si ça se passe au niveau du thème, on définit le nom de la fonction qui sera utilisée. Derrière, on peut bien utilisé ce que l'on veut.
Pour le pb de date, on doit également définir comment ça sera nommé dans la structure du fichier xml.
C'est juste une réflexion qui ne revient pas remettre en question effectué jusqu'à maintenant.
Il existe d'autres alternatives et on peut changer si vraiment on n'adhère plus.
Je ne connais pas tout ce qui a été fait ni discuter. Il y a probablement des choses qui m'échappe mais c'est une proposition.
Le projet reste dans les mains des différents contributeurs mais c'est également le moment d'échanger sur le projet et son avenir.
Pas besoin d'aller les récupérer ailleurs.
Le cas de la page de contact est le plus simple, il est illustré par le thème concept DefoContact, une page statique encapsule tout le tralala avec le formulaire de courriel adapté au visuel des feuilles de style.
Pour la recherche, c'est un peu différent, la complexité du moteur est telle que ce ne serait pas pratique d'enchâsser tout ce code dans un thème. Le problème ne se posait qu'au moment d'afficher le formulaire de requête et la page de résultats, encore une histoire de DIV magnifiquement créées par le designer mais pas toujours faciles à intégrer dans le code. La solution a été de reproduire le script du formulaire et de bâtir une page de résultats à l'avance. L'installation se résume alors à installer plxMySearch et tout fonctionne, on saute l'étape de l'insertion du champ de requête "générique" puisque tout y est déjà.
Résultat, je vais encore militer pour l'intégration de ces plugins au core mais, au moins, mes problèmes n'existent plus. J'en trouverai bien d'autres...
Je remarque que la fonction catList n'inclut pas une variable #cat_description. Cette donnée est probablement très rarement utilisée mais c'est aujourd'hui que je remarque son absence. La donnée est accessible de façon autonome, elle a fait l'objet de sa propre fonction. C'est très pratique mais elle n'apparaît étrangement pas dans la liste des variables affichables dans catList. Je ferai volontier une pirouette de 25 lignes pour extraire ce dont j'ai besoin mais l'ajout serait très apprécié dans une future version, les quelques minutes que cet ajout demandera simplifieront un peu les choses pour les rares fois où le cas se présentera.
Merci à l'avance
pris en compte: https://github.com/pluxml/PluXml/issues/191
Consultant PluXml
Ancien responsable du projet (2010 à 2018)