Questions avant de migrer
Bonjour,
Je découvre PluXml à l'instant après plusieurs années d'utilisation de Kirby puis Grav (toujours aimé bosser en flat file), et j'ai quelques questions avant de migrer (mais il me semble probable que je migre, la simple présence d'un système de commentaires fonctionnel et complet est déjà un argument très fort pour PluXml par rapport à Grav).
1) Tout d'abord, en ce qui concerne le templating, j'ai plus ou moins l'habitude de retirer tout ce qui peut être retiré lorsque je crée un thème, et d'ensuite ajouter des éléments petit à petit en partant de ce minimum syndical pour arriver à un résultat correct. "Est-ce que ça marche ici ?" Dans le sens, est-ce qu'une page doit respecter certaines règles (contenir certains trucs immuables) ou est-ce que sur le principe je pourrais créer un thème vide et le remplir petit à petit en utilisant $plxShow et des includes pour montrer juste ce qui m'intéresse ? (En parlant de $plxShow, j'ai l'impression que c'est très similaire à la syntaxe de Kirby, est-ce une impression juste ?)
2) Ensuite, je m'interroge sur la flexibilité des fichiers xml (fichiers contenants, donc). J'ai repéré qu'il y avait plein de champs prédéterminés et éditables via l'admin, ma question est de savoir s'il est possible d'en ajouter (ou d'en retirer) et d'y avoir accès via $plxShow et autres.
3) Pour ce qui est du champ "content" (et du champ "headline" ou de tout autre champ hypothétique en fait), est-ce qu'il peut contenir n'importe quoi (notamment des div destinées à interagir avec du JavaScript ou du CSS) ou pas ? De même, justement, si je veux inclure du JavaScript par page (par exemple pour un mini-jeu) est-ce possible ?
4) Est-on supposé travailler uniquement via l'admin (et le laisser gérer l'organisation physique des fichiers) ou est-il acceptable de modifier directement le contenu du dossier data comme c'est souvent le cas dans Kirby/Grav, quite à écrire manuellement certaines adresses ?
5) Y a-t-il moyen d'éviter les URL à rallonge ? J'ai l'impression qu'à la création d'article (disons que l'article s'appelle test), PluXML crée systématiquement une URL du style site/article1/test (plutôt que site/test).
6) Bon, et on va dire que dernière question pour l'instant : y a-t-il des trucs que PluXml fait particulièrement mal (ou pas du tout), ou pour les migrants des trucs que Kirby/Grav font mais que PluXml ne fait pas ou fait mal ?
Merci beaucoup de votre attention !
Je découvre PluXml à l'instant après plusieurs années d'utilisation de Kirby puis Grav (toujours aimé bosser en flat file), et j'ai quelques questions avant de migrer (mais il me semble probable que je migre, la simple présence d'un système de commentaires fonctionnel et complet est déjà un argument très fort pour PluXml par rapport à Grav).
1) Tout d'abord, en ce qui concerne le templating, j'ai plus ou moins l'habitude de retirer tout ce qui peut être retiré lorsque je crée un thème, et d'ensuite ajouter des éléments petit à petit en partant de ce minimum syndical pour arriver à un résultat correct. "Est-ce que ça marche ici ?" Dans le sens, est-ce qu'une page doit respecter certaines règles (contenir certains trucs immuables) ou est-ce que sur le principe je pourrais créer un thème vide et le remplir petit à petit en utilisant $plxShow et des includes pour montrer juste ce qui m'intéresse ? (En parlant de $plxShow, j'ai l'impression que c'est très similaire à la syntaxe de Kirby, est-ce une impression juste ?)
2) Ensuite, je m'interroge sur la flexibilité des fichiers xml (fichiers contenants, donc). J'ai repéré qu'il y avait plein de champs prédéterminés et éditables via l'admin, ma question est de savoir s'il est possible d'en ajouter (ou d'en retirer) et d'y avoir accès via $plxShow et autres.
3) Pour ce qui est du champ "content" (et du champ "headline" ou de tout autre champ hypothétique en fait), est-ce qu'il peut contenir n'importe quoi (notamment des div destinées à interagir avec du JavaScript ou du CSS) ou pas ? De même, justement, si je veux inclure du JavaScript par page (par exemple pour un mini-jeu) est-ce possible ?
4) Est-on supposé travailler uniquement via l'admin (et le laisser gérer l'organisation physique des fichiers) ou est-il acceptable de modifier directement le contenu du dossier data comme c'est souvent le cas dans Kirby/Grav, quite à écrire manuellement certaines adresses ?
5) Y a-t-il moyen d'éviter les URL à rallonge ? J'ai l'impression qu'à la création d'article (disons que l'article s'appelle test), PluXML crée systématiquement une URL du style site/article1/test (plutôt que site/test).
6) Bon, et on va dire que dernière question pour l'instant : y a-t-il des trucs que PluXml fait particulièrement mal (ou pas du tout), ou pour les migrants des trucs que Kirby/Grav font mais que PluXml ne fait pas ou fait mal ?
Merci beaucoup de votre attention !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'essaye de répondre à tes questions
1) Au niveau du thème, tu peux supprimer ou rajouter ce qui est nécessaire ou pas en fonction de tes besoins. Quand dans les fichiers du theme tu vois $plxShow c'est qu'une fonction de PluXml est appelée pour restituer des infos venant de PluXml. Si tu n'en a pas besoin, tu supprimes la ligne et ça ne casse rien. Le theme en lui même tu le construis comme tu veux au niveau balisage (par exemple des themes de wordpress ont été repris avec sa syntaxe html, juste l'appel des fonctions de wordpress ont été supprimées et remplacées par celles de PluXml).
Il suffit donc d'aller placer ces instructions "$plxShow" aux endroits voulus pour récupérer les infos à afficher venant de PluXml.
idealement le mieux est de se caler sur le thème par défaut et de le modifier en fonction de tes besoins. Ce thème est volontairement "basique" justement pour permettre de se l'approprier et de le personnaliser en fonctions de ses besoins.
2) les champs rajoutés manuellement dans les fichiers xml ne seront pas pris par PluXml et leurs données ne seront pas exploitable. il faut développer un plugin qui fera le lien avec PluXml pour manipuler les données
3) le code (php ou javascript) n'est pas pris en compte dans les articles. Il l'est dans les pages statiques. il y a toujours la possibilité de rajouter du code dans les fichiers du thème. Exemple en éditant le fichier article.php du thème, on peut mettre du javascript. en revanche, ce code sera exécuté pour tous les articles. ou alors il faudra conditionner son execution en fonction du n° d'article affiché par la page (une variable PluXml est dispo pour savoir quel n° d'article est utilisé quand le fichier article.php est utilisé coté visiteur). il faudra donc rajouter du code php dans le fichier article.php pour étendre des fonctionnalités. Mais en gros on peut faire un peu tout ce qu'on veut dans ces fichiers (rajouter du jquery, coder des choses en durs, etc...)
4) conseillé de passer par l'admin, mais tu peux éditer les fichiers xml avec un éditeur de texte genre notepad. il faut veiller alors à ne pas casser la structure xml des fichiers. mais c'est donc + contraignant et beaucoup moins pratique.
5) plugin MyBetterUrls: http://forum.pluxml.org/viewtopic.php?id=4087
dispo ici: http://pluxopolis.net/myplugins
6) je ne connais pas Kirby/Grav donc difficilement de les comparer.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
1) 2) Ok, c'est très clair. Il faudra que j'aille lire le manuel des plugins mais ça devrait aller, la documentation semble robuste. (Juste une précision, les balises html fonctionnent complètement ? Pour les id, class, etc..)
3) J'ai l'impression que l'idéal serait de coder un plugin d'assets, genre un champ optionnel ajouté aux pages qui lorsqu'il contient des noms ou adresses de fichiers ("script.js", "look.css" ou encore "scripts/script1.js" par exemple) les charge au moment de la génération de la page. Pas d'obstacle particulier au-delà de "il faut coder le plugin", je suppose ?
4) D'accord, je pense qu'effectivement je passerai plutôt par l'admin du coup.
5) Thanks!
Je dois dire que je suis super impressionnée et enthousiasmée par ce CMS, merci beaucoup de l'avoir créé !
Le thème par défaut de PluXml utilise le framework css PluCSS: http://plucss.pluxml.org/
C'est un développement maison fait spécifiquement pour PluXml. ça évite de réinventer la roue.
Mais après rien ne t’empêche de faire l'impasse dessus et d'en utiliser un autre comme bootstrap, w3css, knacss, etc..
Si on a développé PluCSS c'est pour avoir une framework css le plus light possible et qui réponde au mieux à PluXml pour éviter de l'alourdir inutilement et terme de syntaxe mais aussi de performance.
3) pas d'obstacle effectivement. le seul obstacle est celui des compétences de chacun à coder et les connaissances de core de PluXml pour venir y greffer ce dont on a besoin. Il y a aura certainement une limite à tout faire à un moment, parce que la structure de PluXml ne le permettra pas, ou ça deviendra + une usine à gaz que quelque chose de propre. Mais en attendant y a de la marge...
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)