Projets et pistes d'améliorations
Haruka
PluXml Project Manager
Bonjour à tous,
Comme promis, je partage avec vous les axes d'évolutions qui vont animer cette année 2020, avec à la clé une version 6.0 de PluXml. Mais qui dit version majeur, dit changements majeurs.
Avant de parler de PluXml, quelques éléments autour du site pluxml.org. En effet, tous les utilisateurs de PluXml ne sont pas francophones et c'est pourquoi, je souhaite passer le site en multilingue français/anglais. C'est une grosse charge de travail, puisque cela implique de traduire toute la documentation et de publier des articles sur le blog dans les deux langues. Bien sûr je n'oublie pas qu'il manque un véritable espace "Ressources" collaboratif et sécurisé.
PluCSS
Le système de grid du framework CSS intégré à PluXml doit évoluer pour s'aligner avec les derniers standards du web, et intégrer "grid layout" à la place du système de grille actuel. Il manque également certains éléments qui pourrait être intéressants pour l'administration de PluXml, à savoir une gestion d'onglets et de toggles, par exemple. Enfin, je me pose aussi la question d'utiliser SASS.
En parallèle, je réfléchis au remplacement et donc à l'abandon de PluCSS au profit d'un autre framework, tel que Knacss. Ce qui me permettrait de me concentrer pleinement sur PluXml et de profiter d'un framework plus complet, mais moins léger.
PluXml
A plusieurs reprise sur le forum, il a été évoqué de retravailler le code de PluXml en profondeur, que se soit dans une vision OOP ou plus simplement des refacto sur le moteur. Avec la version 5.8, Composer a été intégré pour gérer les dépendances de PHPMailer, ce qui me fait penser à revoir complètement la structure de PluXml pour le rendre plus respectueux du modèle MVC et pourquoi pas, migrer vers un framework PHP, tel que Laravel (avec l'aide de Composer). Il faudra, néanmoins, garantir la rétrocompatibilité des plugins et des thèmes.
En vrac, des idées d'évolutions (à compléter avec les issues ouvertes sur Github) :
- Intégrer un éditeur wysiwyg en natif
- Intégrer la recherche en natif (plxMySearch)
- Nouveau thème pour l'administration
- Remplacer la notion de “page statique” par une notion de “page”
- Création d'un gestionnaire de média “light” pour l'ouverture en popup dans l'édition d'articles/pages
- Dans article.php à la création d'une catégorie, sélectionner automatiquement celle-ci, si aucune catégorie n'est déjà sélectionnée
- Intégrer une sauvegarde automatique des brouillons
- Sauvegarder le site dans un zip à télécharger via un bouton
- Ajouter une mécanique de redirection d'URL sur les articles et sur les pages statiques
- Ajouter une mécanique de "remember me"
- Suppression des meta keyword (ne sont plus pris en compte par Google)
- Thème par défaut : ARIA, schema.org, opengraph, maillage interne SEO
A vous !
N’hésitez pas à me communiquer vos idées ou souhaits.
J'aimerais également connaître votre avis sur l'avenir de PluCSS, préférez-vous qu'il soit remplacé ou faut-il continuer de le maintenir et de le faire évoluer ?
Que pensez-vous de migrer PluXml vers un framework PHP, tel que Laravel ?
Réponses
Bonjour,
Pour moi il y a deux sujets à traiter dans l'ordre et non mener les deux de fronts.
Framework
Je suis partagé pour l'utilisation d'un framework. C'est à la fois un moyen d'attirer de nouveau dev mais c'est aussi un moyen de faire peur à des non dev, je m'explique.
Actuellement PluXml utilise sont propre "framework" qui est très simple à prendre en main même pour un dev débutant et ne nécessite pas de faire le ping pong entre les ressources propres au framework et celles de PluXml. Parfait pour une personne ne souhaitant pas aller plus loin que PluXml.
Maintenant je me place du côté d'un intégrateur (je suis dans cette situation) travaillant sur plusieurs solutions suivant le besoin client. Il va forcément investir du temps d'apprentissage sur des solutions s'appuyant sur des ressources éprouvées et/ou communes. Typiquement le framework Symfony (largement trop lourd pour PluXml). Du coups avec le framework maison il risque de passer son tour car pas le temps d'apprendre encore une nouvelle structure et limité à une solution.
Je suis d'avis de passer sur un framework "standard" mais attention jusqu'à présent tout ceux que j'ai croisé nécessite de passer par composer en ligne de commande ce qui élimine tout les hébergeurs ne le proposant pas la CLI... Ou alors je suis passé à côté d'un truc.
Fonctionnalités
C'est une bonne idée car il y a toujours un petit truc à ajouter et je pense que PluXml doit sortir de l'image d'un CMS basique. Il faut être honnête, même une personne voulant faire un site statique passe par Wordpress car il est souvent proposé en module installable par les hébergeurs. Du coups si PluXml veut sortir du cercle très fermé des CMS français, sans base de données... Il doit se doter d'un panel de fonctionnalités facilitant la vie des rédacteurs/créateurs de contenu.
Conclusion
Comme je l'ai dis en intro, il y a deux sujets qui doivent être traités mais attention à le faire dans le bon ordre. Changer de framework et par la suite ajouter des fonctions ou ajouter des fonctions et changer de framework. Par expérience il est plus simple de faire un changement profond sur une base solide et simple dit à ISO-périmètre. Une fois tout stabilisé alors on peut monter en puissance et fonctionnalités. L'inverse est une erreur qui pourrait mener à un retour en arrière voir pire à la mort du CMS (expérience vécu pour un projet ERP).
Mon avis reste orienté usage professionnel / intégrateur car c'est dans ce cadre que j'utilise PluXml mais est-ce que le commun des mortels a encore besoin d'un CMS tellement de solutions toutes faites existe ?
J'ai un string de l'array
Petite expression régulière: "s/souhaiterais/souhaite/" ( sinon tu est toujours dans le doute et tu gardes des problème d'accord avec le verbe )
Si on veut que PluXml se développe il est certain qu'il faut s'ouvrir au monde non francophone. Et je ne parle pas de la France. En informatique dès qu'on commence à toucher à la programmation, le minimum syndical est de lire l'anglais. Je réclame depuis un moment une rubrique anglophone sur ce forum. Si la demande est là, on peut aussi envisager des rubriques russophones, la culture française a une certaine aura dans ces régions, et peut-être hispanique, pas seulement pour l'Espagne mais aussi pour l'Amérique du Sud.
C'est une très bonne nouvelle d'apprendre qu'on envisage l'abandon de PluCSS. Il n'est pas tolérable d'utliser des "float: left". Il y a belle lurette que les "display: grid" et display: flex" sont sortis et font bien mieux le taf. Développer un gestionnaire de CSS est chronophage. Donc inutile de réinventer la roue et prenons ce qui existe. Knacss est un bon choix. Il est relativement simple à adopter. Il s'appuie sur SASS sans qu'on soit obligé de le connaitre. Mais cela permet aux plus experts de personnaliser davantage. De plus, les gens d'Alsacreations sont plutôt sympas.
Adopter un framework PHP comme Laravel ou autre ne me semble pas une bonne idée. PluXml risque d'être pas mal chamboulé et ceux qui développent des plugins n'auront plus de repère.
Par contre, il faudrait utiliser SimpleXml en remplacement du parseur XML actuel. Dans la structure des données, on est toujours limité à un niveau et rend impossible l'utilisation de tableaux. On bidouille en ajoutant un suffixe numérique au nom des paramètres pour contourner le problème. On peut également s'interroger sur l'intérêt de conserver le format XML qui est très verbeux au profit du format JSON plus populaire et qui s'exploite très bien en Javascript.
Pour rester dans les données, il faudrait séparer les méta-données du corps des articles comme pour les pages statiques pour les stocker dans un fichier articles.xml comme statiques.xml. Cela éviterait de balayer tout le répertoire data pour trier et classer les articles. On peut s'interroger de la pertinence de tous les fichiers XML suivants :
categories.xml
parametres.xml
plugins.xml
statiques.xml
tags.xml
users.xml
et s'il ne serait pas plus efficace de les regrouper dans un seul fichier avec une structure xml à parser une fois avec simpleXml.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Je n'ai pas d'opinion sur l'utilisation ou non de Laravel (ou de quoi que ce soit d'autre), le développement n'est pas mon domaine. Mais si je peux me permettre (en tant qu'intégrateur ET utilisateur), une des priorités devrait porter sur la réécriture du menu frontend qui manque de souplesse dans l'ordonnancement des items. Et un menu bien structuré c'est quand même très important (notamment en terme d'accessibilité). En ce sens, l'intégration par défaut d'un moteur de recherche est une excellente idée.
Par contre, je milite (depuis longtemps) pour l'abandon de PluCSS :
Pour ARIA et schema.org, je suis intéressé, pour le SEO beaucoup moins (les futures tendances, d'après un pro du milieu SEO, vont plutôt vers de la recherche "intelligente" de contenu partagé et contextualisé mais ça a l'air encore plus complexe que le SEO !)
Bon courage à l'équipe et merci pour tout ce travail ! :)
Pour l'éditeur wysiwyg, laissons le choix à chacun. On peut simplement recommander des plugins testés CKEditor, TinyMCE, CodeMirror.
Le changement de thème du back-office découlera simplement de l'adoption de Knacss.
Une approche plus intéressante serait de faire une application OnePage avec Vue.js pour réduire le rechargement complet de chaque page à la moindre modif. L'adoption de JSON aidera dans cette direction.
Effectivement ce terme "statique" est un peu perturbant dans les URLs pour les non-initiés. "page" serait plus parlant par opposition à "article". Il faut également arriver à supprimer ces numéros d'articles et de statiques dans les URLs. Je suis obligé de corriger PluXml à chaque nouvelle release pour virer ces numéros.
Un bouton pour télécharger une archive zip du dossier data est une bonne idée.
Autre point, il serait bien d'enregistrer la date de dernière connexion de chaque utilisateur et de l'afficher pour contrôle à la prochaine connexion. C'est une simple mesure de sécurité.
Puisque les adresses mails sont enregistrées, on peut prévoir un système de notification vers les administrateurs ou les auteurs pour tout nouveau commentaire ou article à modérer. C'est une fonctionnalité importante qui manque.
Le systéme d'authentification pour le back-office à 3 coups est une grosse rigolade et ne résistera pas longtemps à une attaque par "force brute". Il y a juste à virer tous les cookies à chaque essai. Soit passer à la double authentification, j'ai déjà créé 2 plugins pour cela, soit isoler le login et le mot de passe dans 2 pages différentes, soit mettre un captcha, ou mettre en place un clavier virtuel comme pour les banques.
Rajouter une 6ème catégorie d'utilisateurs sans droit d'écriture. Peut servir dans le cas d'adhérents d'un club ou d'abonnés.
Voilà ! Je n'ai plus d'idée à vous proposer pour ce soir. 😀
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Petit oubli de ma part :
Il faudrait virer le dossier data de l'archive ou de la release. Il n'y a plus grand chose dedans et le fichier install.php devrait le créer complétement s'il est absent.
L'intérêt est de pouvoir repartir sur un site tout neuf simplement en renommant le dossier data en data.bak par exemple. On peut ainsi basculer simplement d'un dossier de données à un autre en modifiant les paramètres avancées ou avec le plugin moveMyDatas.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Pour moi, tant que cela reste un CMS simple, léger, portable, sans BDD, sans javascript et sans appel vers des sites externes pour fonctionner, cela m'ira.
Je suis venu à PluXml en quittant Wordpress qui m'était devenu une usine à gaz pour afficher un blog perso avec quelques pages ou un site professionnel basique pour des utilisateurs non technophiles. Il s'agirait de ne pas faire de même avec PluXml.
J'ai constaté la différence entre les deux CMS, aussi bien en terme de charge sur mes serveurs web ou la bande passante utilisée, PluXml remporte le duel haut la main.
Concernant PluCSS, j'avoue que sa facilité d'utilisation est un plus et l'utilise sur d'autres sites.
Salut je réagis aux commentaires précédents en tant qu'utilisateur "averti" qui a développé quelques plugins.
Concernant le menu frontend pour appuyer ce que dit Gzyg c'est la seule chose que j'ai remaniée en profondeur sur le site que je gère pour une grosse association. Cela permet de regrouper des pages statiques dans le menu en haut et pour chaque entrée du menu, on affiche une page statique avec un template qui reprend le sous-menu dans un cadre de la page. Le sous-menu est constitué de toutes les pages statiques qui ont la même catégorie mais ne sont pas dans le menu (puisqu'on peut activer la présence dans le menu par page). C'est une fonctionnalité qui pourrait facilement se retrouver dans le code standard de pluxml puisque c'est principalement basé sur un template. L'affichage du menu principal par contre est un peu différent du standard, il faut chaque fois revérifier quand on monte de version. Je suis tout à fait prêt à partager le code si cela intéresse l'équipe.
Donc pour résumer je pense que beaucoup d'améliorations sont possibles sans toucher à l'essence du projet et sans complexifier les fonctionnalités existantes (d'un point de vue utilisateur). L'utilisation d'outils comme Knacss peut aussi simplifier la vie de l'équipe, un point important pour conserver l'envie de maintenir cet outil magnifique qu'est pluxml (je pèse mes mots). Déjà merci pour la version 5.8 (5.8.1) et j'espère que vous continuerez avec motivation.
@Fogg,
Les fichiers JSON peuvvent être très lisibles si on le veut. Mieux qu'avec XML. Voici un bout de code pour démo :
<?php const URL = 'https://de1.api.radio-browser.info/json/stations/search?state=Auvergne-Rh%C3%B4ne-Alpes&countrycode=FR'; $content = file_get_contents(URL); $radios = json_decode($content, true); header('Content-Type: text/plain'); echo json_encode($radios, JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES); ?>Sauvegarde ce code dans un fichier nommé par exemple : json.php
Place toi dans le dossier de ce fichier et tape php -S localhost:8080
affiche le rendu de la page dans ton navigateur à l'adresse http://localhost:8080/json.php
Et voici l'adresse pour les mêmes données au format XML :
https://de1.api.radio-browser.info/xml/stations/search?state=Auvergne-Rh%C3%B4ne-Alpes&countrycode=FR
La visibilité n'est qu'une question de choix.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour !
Pleins de bonne idées ! je suis content de voir que pluxml continue d'évoluer petit à petit !
Pour ma part je n'ai pas vos compétence de développement a part bricoler le thème de mon site quelques notion d’intégration de script et voila. (Je travail actuellement sur la création d'un nouveau thème que je partagerai avec vous bientôt). Dans un futur proche je vais aussi me pencher sur la création de plugin, je trouve (pour ma part et mon utilisation) que c'est ce qu'il manque le plus, des plugins plus évoluer comme par exemple permettre au visiteur de s'inscrire pour commenter un article, avoir un profil avec éventuellement d'autre plugin qui pourrez permettre d'avoir une messagerie très simple entre membre, uploader une photo de profil, etc...) afin d'avoir des petit site plus évoluer sans avoir à passer par wordpress ou autre usine avec bdd SQL.
Pluxml n'a pas besoin de beaucoup de fichier pour fonctionner, pendant son évolution j'esper qu'il restera compact, simple et léger :)
Mon message ne vous sera pas d'une grande utilité en tout cas merci à vous pour tout les effort apporter a la communauté pluxml :)
Merci pour vos retours. Je note les idées et propositions.
Je pense qu'on peut donc partir pour un remplacement de PluCSS par Knacss dans la prochaine version de PluXml.
Le framework PHP, je vous rejoins, on travaillera à améliorer PluXml sans passer par ce type d'outil.
SimpleXML, je suis totalement pour.
Quant à VueJS et le format JSON, c'est effectivement très intéressant et ça pourait être intégré progressivement à PluXml. Je vais faire quelques tests et voir ce que ça pourrait donner.
En effet, une refonte de PluXml dans le sens de l'internationalisation de ce dernier serait bonne pratique, sachant que la plupart des fonctions (si ce n'est pas toutes) sont déjà en anglais. Ce qu'il faut, comme déjà dit, c'est d'utiliser l'anglais partout (donc les noms de fichiers par exemple). Pour garder le côté "français" ce que l'on peut faire est d'ajouter un protail anglophone au site PluXml (par exemple une simple traduction de ce dernier disponible sur https://en.pluxml.org/ et garder le français sur www).
Par contre l'utilisation d'un framework je suis assez mitigé. C'est justement ce que je trouve pratique dans PluXml.
FR/EN MP - Mail - unkorneglosk.fr - Twitter - Je suis modérateur, je dois donc modérater. Ou modérationner. Ou je sais plus. Mais je le fais. En ce moment j'ai des problèmes d'accès à internet je peux mettre du temps à répondre.
Petit oubli dans mes suggestions :
Descriptions multilingues dans le fichier infos.xml des plugins. Actuellement seulement une seule langue possible.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
oui et tu as fait le choix de quelque chose pas très interprétable par un humain au niveau du xml.
par contre ton fichier json est interprété par un outil avant d'être lisible par un humain. avec l'outil oui, il est lisible.
créer un fichier xml à la main, est aussi bien plus simple que de créer un json.
et des outils pour lire les xml, il y en a à la pelle. du reste bcp d'outils bureautiques lisent les xml (Excel, etc)
bref c'est comme tout, ça se discute.
Petite idée d'ajout pour la prochaine version :
Ajout de paramètres dans "StaticList" afin d'offrir la possibilité de filtrer par identifiant ou par nombre de pages, voire par groupe de page, à la manière de "CatList" ou "TagList".
Par ailleurs, je pense que la documentation de plxShow pourrait être enrichie, afin que les utilisateurs puissent se rendre davantage compte de la puissance de ce qui est proposé (et donner plus d'idées de développements simples pour les utilisateurs).
Merci pour tout !
Filtrer par identifiant renverra toujours une liste de ... 1 page. Pas trop d'intérêt. Autant appeler la page directement
On pourra effectivement rajouter un paramètre pour filtrer par groupe si le menu en cascade ne convient pas. Attention dans le filtre de faire la différence entre les pages qui n'ont pas de groupe et pas de filtrage ( $group='' vs $group=false )
On pourrait également filtrer par template
Pour le nombre de pages, je ne vois pas trop .
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour,
Revenant tout juste revenu, je vous invite à jeter un oeil au framework Fat-Free Framework
Il est vraiment très simple à prendre en main et très léger et pourrai, je pense, être utilisé dans PluXml.
Bonjour !
À mon tour de participer à cette discussion.
Bon mon dada c'est l’internationalisation vous l'avez bien compris depuis le temps que je traîne sur ce forum.
Traductions
En ce moment pour ajouter ou mettre à jour une traduction il faut passer par la forge logicielle GitHub. J'ai connu l'époque où j'envoyais les fichiers par courriel ^^ PluXml y gagnerait à utiliser une interface de traduction telle que weblate. C'est un outil open source qui permet donc de traduire, suivre les traductions mais aussi assurer la qualité des traductions grâce à des contrôles. L'outil peut se connecter à GitHub pour envoyer les traductions. On peut surveiller un projet et être notifié de nouvelles chaînes à traduire, on peut utiliser des mémoires de traductions pour traduire plus vit et/ou de manière harmonieuse. Weblate permet d'éviter par exemple qu'une clef/valeur soit absente d'un fichier de langue ;)
Balises HTML
Il faudrait faire une passe sur les fichiers pour profiter des nouvelles balises telles que autocomplet=new-password
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete
Pareil pour les noms d'utilisateurs, les champs obligatoires avec required
2 versions
Proposer un PluXml nu et un PluXml avec une sélection d'extensions pouvant convenir au plus grand nombre. C'est assez dommage de devoir aller chercher une extension pour avoir un formulaire de contact.
Forum
rétablir l'ancien forum, franchement je ne retrouve rien avec celui-ci...
@Rubén
Weblate a l'air bien cool. :)
l'autocomplete, je ne suis pas pour : ça rend feignant et amnésique ! :)
Le minimum requis pour les extensions par défaut sur un PluXml nu serait le moteur de recherche (obligatoire pour l'accessibilité). Le formulaire de contact est un plus quasi incontournable.
Les commentaires pourraient être optionnels (les réseaux sociaux leur ont retiré une bonne partie de leur intérêt).
L'ancien forum me manque aussi.. et pour les mêmes raisons. :D
Merci pour ces propositions. Je ne connaissais pas Weblate, c'est très intéressant pour rendre plus accessible la traduction à ceux qui ne connaissent pas git.
Proposer deux versions de PluXml (avec et sans plugins intégrés), j'y pense oui ;-)
Bonsoir,
de mon coté c'est les commentaires qui fachent, d'abord il se suivent pas quand c'est une réponse, un petit décalage pour qu'on voit bien que c'est une réponse ç un commentaire serait pas mal, il me semble qu'avant c'était le cas.
Le captcha par défaut aussi, trop facilement trompable pour spammer.
ensuite de mon coté il faut un vrai éditeur, ayant pour l'habitude de markdown (une fois goûté, il n'y a plus rien d'autre) je serais pas contre un éditeur markdown.
Ah j'oubliais, que PluXml reste aussi léger et rapide, c'est le plus rapide des CMS testés. Il rivalise pratiquement avec mon site en statique (Hugo ou Pelican).
J'ai beau essayer la concurrence (Flextype, Grav, Bludit), j'y reviens toujours 😊
Y'a que l'admin qui n'est plus très ergonomique et lisible avec les années (suffirait de copier/coller la concurrence).
Sinon @P3ter , @P3ter "Création d'un gestionnaire de média “light” pour l'ouverture en popup dans l'édition d'articles/pages".
En faite il existe depuis des années lorsque l'on choisis une illustration de couverture, non ? Pour quelle raison n'a-t-il jamais été utilisé dans la barre d'outils de rédaction ?
@seb95 Merci pour tes retours. Concernant les commentaires, si on parle bien de la même chose, il s'agit d'un bug de la version 5.8, corrigé en version 5.8.2 (dernière version disponible).
@Alba Concernant la popup qui s'ouvre au clic sur le "+" de l'image d'accroche, il s'agit en fait de la page medias.php qui correspond au gestionnaire de médias accessible via le menu de l'admin. L'idée d'une nouvelle popup serait de proposer une écran sans les fonctionnalités de création des miniatures, de renommage des fichiers, etc. et qui serait plus simple pour naviguer dans les dossiers et sélectionner une ou plusieurs image. C'est juste une idée à creuser, rien de révolutionnaire pour l'instant.
En terme d'ergonomie de la partie admin, il serait bien de s'inspirer de celle de textpattern.
C'est clair, propre et fonctionnel. Il y a une démo à cette adresse : https://textpattern.co/demo
Merci P3ter,
Oui c'était bien cela. Amicalement
Ah et j'oubliais, effectivement j'ai beau testé les autres comme grav et compagnie, je reviens toujours sur pluxml pour un dynamique sans BDD et léger.
Petit idée à l'usage : proposer la possibilité pour chaque page / article d'avoir un titre différent de ce qui s'affiche dans le menu, étant donné que l'insertion dans celui-ci est automatisée. Ça ferait donc un champ en plus avec un intitulé du genre "texte du menu", optionnel, et rempli automatiquement par défaut.
Ça permettrait une plus grande souplesse, et pas mal d'autres CMS le permettent.
"Mais si je peux me permettre (en tant qu'intégrateur ET utilisateur), une des priorités devrait porter sur la réécriture du menu frontend qui manque de souplesse dans l'ordonnancement des items. Et un menu bien structuré c'est quand même très important (notamment en terme d'accessibilité). En ce sens, l'intégration par défaut d'un moteur de recherche est une excellente idée." Gzyg
Complètement d'accord : la construction du menu manque singulièrement de souplesse, l'accueil, d'un côté les catégories, de l'autre les pages… pas super pratique à agencer. Et pouvoir agencer des sous-menus paramétrables dans les gabarits, ça pourrait être bien, j'ai vu une proposition en ce sens par Fogg.
Je n'ai jamais utilisé PluCSS ni même compris l'intérêt d'avoir un framework CSS dédié alors qu'il y a de bonnes solutions légères comme Knacss ou Rocssti que j'utilise régulièrement.
+1 aussi pour l'internationalisation
+1 pour cleaner les urls par défaut (et non à l'aide d'un plugin - MyBetterUrls - comme c'est le cas actuellement)
+1 aussi pour revoir l'ergonomie de l'admin qui n'a que peu évolué et n'est pas au top, notamment avec des sous-menus : il faudrait pouvoir les déplier en JS par ex., avoir un sous-menu dédié pour les plugins, ce genre de choses.
Inutile d'utiliser Javascript pour déplier un truc, cela se fait en HTML + CSS pour un dépliage statique ou uniquement en CSS pour un dépliage dynamique.
Pour le nettoyage des urls, il faudrait virer ces numéros d'articles et de pages statiques comme je le fais sur https://www.echecs-annonay.fr . Mais à chaque nouvelle version je suis obligé de reprendre le code de PluXml parce que les expressions régulières sont mal maitrisées. Du coup, j'ai laissé tomber les mises à jour.
Pour la partie admin, le menu de gauche occupe de la place inutilement pendant la rédaction d'un article, d'une page statique ou l'édition d'un thème. De plus il s'agrandit au fur et à mesure qu'on étend la fenêtre.
J'avais également suggéré qu'on s'oriente vers vue.js pour avoir une admin plus réactive mais apparemment c'est très mal parti.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
IL y a une intéressante discussion sur Twitter actuellement à propos de PluXml. Si vous avez un compte faites une recherche sur "pluxml".
L'absence d'aide en anglais pour PluXml rebute les personnes qui ne maitrisent pas le français.
Je me demande toujours ce qu'on attend pour ouvrir une rubrique uniquement anglophone dans ce forum et le faire savoir haut et fort.
Il y a quand même plusieurs personnes sur ce forum qui maitrisent plus ou moins l'anglais, qui pourraient aider des non francophones et également perfectionner leur anglais en le pratiquant davantage.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Ce qu'on attend, c'est juste d'avoir un peu de temps. Mais oui, j'aimerais passer tout le site pluxml.org en français/anglais (à commencer par le forum). On va voir ce qui est faisable avec Vanilla.
Bonjour, merci pour ces projets.
Pour ma part je ne suis pas intéressé par un framework. Tout l'intérêt de PluXML à mes yeux est sa légèreté et sa simplicité. Avec quelques bases en PHP on peut faire ce que l'on veut.
Concernant la légèreté, j'avoue avoir laissé mon PluXML en version 5.7 car le poids du 5.8 a considérablement augmenté. Je ne suis plus capable de l'installer sur mon hébergement gratuit de 10 mo.
Je pense qu'il y a un équilibre à trouver entre fonctionnalités et légèreté/simplicité.
Merci