Knacss est plus populaire que PluCss et plus simple. Et Knacss est bien soutenu par ses auteurs.
Le débat sur un framework CSS ne porte que sur le coté back-office de PluXml.
Côté thème, tu peux choisir le système de grille que tu veux ou pas. Avec les "display:grid" ou "display: flex", que ne supporte pas PluCss, les systèmes de grille présentent moins d'intérêt.
Qu'entends tu par les "security headers" ?
Pour les caches de plugins, ce n'est pas évident. Certains emploient des scripts JS, des feuilles CSS, des images. Et on peut ne pas les cacher. La seule chose à faire est de mettre la règle qui va bien dans un .htaccess pour empêcher d'appeler directement les fichiers .php. Et les fichiers .htaccess ne sont pas pris en compte par Nginx.
Si tu recherches du code PHP optimisé, il faut regarder directement la branche master sur le dépôt Github et tester.
On ne pourra avancer que lentement si peu de gens testent la prochaine version pour faire des remontées de bogues.
Pour la base de plugins mise à jour, c'est quasiment impossible. Cela prend beaucoup de temps. Par contre, ce qui manque c'est un système de notation pour les plugins et un dépôt centralisé des plugins "non officiels".
Pour Plucss, je trouve ça dommage, surtout pour les personnes qu'ils l'ont développé. Il suffirait peut-être d'y apporter les modifications
nécessaire pour qu'il satisfasse tout le monde. Et si Knacss décide d'arrêter ou de changer radicalement leur formule, faudra à nouveau tout réécrire.
Bref je trouve que c'est du détail ça par rapport à la structure même de Pluxml. Et du moment qu'on peut encore rajouter des class CSS à l'interface Admin, ça me va.
D'ailleurs le fait de pouvoir changer le nom du dossier Admin me parait être une bonne idée, c'est dèjà le cas sur d'autres platormes.
Pour les sécurity Headers, je me suis peut-être un peu emballé. je pense que développer un plugin officiel serait mieux.
Pour le Cache des plugins, oui c'est pas évident, puis il y a des déjà des plugins qu'il le font. C'est vrai que moi je parle de ça parce que
j'ai quelques sites sur les pages persos Free, et le htaccess, bah il y a pas grand chose qui passe avec. J'ai dû tout faire à la main.
Une autre chose c'est la fonction recherche intégrée, je trouve que c'est une bonne idée, même si ça va alourdir encore un peu code, il faudra pouvoir le désactiver si nécessaire.
J'ai eu une autre requête, c'est pour la page commentaires.php, il faudrait essayer d'externaliser le script de réponse aux commentaires.
Affaire à suivre @+
1) passer dans le monde Anglophone .
Ayant délaissé(4.1 la toute derniere version que j'avais télécharger ) PluXml durant une dizaine d'année , j'ai eté agreablement surpris de voir de l'anglais dans les pages du site mais aussi autant surpris qu'il n'ait pas un minimum pris dans les communauté anglophone. revenant sur PluXml pour redémarrer un projet (covid-19 à foutu un gros coup dans les relation sociales non virtuelles) Il m'a vite démange d'aller créer un nouveau tag sur stackoverflow.com (entre autre) et y poser mes quelques questions php et je me suis vite raviser. ce n'est pas mon rôle et cela demande probablement un peu plus de réflexions, expertise sur PluXml et aussi de disponibilités. Pour le coup je ne cochais aucune case.
2) PuxCss ou autre , tout dépend des utilisateurs. si des thèmes par défauts
- basé sur PluxCss, bootstrap , knacss, autre ou juste avec un reset classique et standard *(et puis sera t-il toujours nécessaire au vu des belles évolutions de nos navigateurs ces dernières années?)
- une structure minimale mais bien construite (structure html avec une sémantique pertinente et sa touche wai-aria)
sont proposée, chaque nouvelle utilisateur pourra démarrer a partir d'un thème par défaut et de ses framework qui lui parle et lui convient. ce qu'il faut c'est au moins un thème neutre, pas épuré ou minimaliste mais sans style qui permette simplement d'afficher le contenu.Perso , ce serait mon choix car je ne suis pas mal à l'aise avec les feuilles de styles et j'ai , comme beaucoup d'autres, mes opinions sur tel ou tel framework. Mais un devops, qui veut se faire son petit blog pour communiquer auprès d'un public restreint se contenteras d'un thème par défaut, d'un bootsrap et d'un des thémes de bootstrap. Ce sera un utilisateur satisfait et aussi un ambassadeur malgré lui
Quand on jette un oeil sur des projets en react par exemple, on comprend tout de suite que le gars qui veut faire un truc simple vite fait ne vas pas se recoltiner un PluxCss quant il a éventuellement l'habitude d'un bootstrap pour injecter ses styles.
3) simpleXml ... oui, lorsque que j'ai découvert pluxml a ses début, c'est ce que je me suis demandé, pourquoi non ? Dix ans plus tard, des portions du code de PluXml me sont toujours familière et semble inchangée.(a part le thème initialement composé d'un unique fichier : template.php breakant sur le mode en cours... et le nombre de fichier de class qui ont fait des petits )
Sans être développeur, certaine partie du code semble vraiment redondante mais traitant des fichiers de structures différentes . Pourquoi pas, mais alors pourquoi ne pas en faire une spécificité en réduisant ces fonctions similaires en une seule , plutôt que de reprendre d'autres scripts dont on va faire un assemblage et renommé PluXml? PluxJson pourrait aussi prendre la releve aprés tout . Non, Gardons cette French-touch
Au début j'ai naïvement pensé que l'Xml était un atout dans le sens ou de nombreux autres logiciels en faisait usage et je voyais le blog communiquer et se transformer aisément en pdf, ebook, fichier word ou openOffice et vice versa, mais non, un fichier .ini, .txt ou . csv aurait tout autant fait l'affaire au début .(c’était aussi les belles heures de XHTML ) .
4) la retro compatibilité, cela a toujours posée quelques soucis , mais des plugins d'exportations du contenu et de la config d'une version x vers une version plus récente à chaque modifs majeure pourrait suffire. à propos , un update d'une version 3 a la version 5.8.6 (~2009 =>2020), personne n'as ? NaN , je rigole. Pour les plugins ? Oui, effectivement, les plugins les plus utiliser et aboutie devrait mériter de devenir partie intégrante de PluXml et rejoindre ces fichiers class.plxmachin.php . Liste qui s’étoffe depuis les débuts de PluXml. Perso, en 2008 j’avais en base un formulaire de mail/contact(static), un site map(static), googlemap(static), un plug gallerie tri et légende, un éditeur simple avec en sus une petite table de caractére HTML et son popup en preview(live ou pas dans le thème en cours) avec l'insertion d'un template dédier au thème(initialement mis en place pour ma sœur et ensuite customiser pour les autres), le plugin user et des répertoires médias distinct par user, Ckeditor avait toute ma sympathie( mais faisais beaucoup grossir l'archive), ... bref, aujourd'hui beaucoup de ses choses ne nécessite plus de greffons et c'est super.
5)Oui PluXml est facile d'utilisation et accessible aux débutants et j'espère que cela restera ainsi. C'est pour beaucoup sa marque de fabrique et surement l'une de ses qualités.Une courbe d'apprentissage courte est un atout et une demande réel aujourd'hui (quel que soit le domaine). tout le monde imagine qu'un clique et une feuille de calcul peuvent tout résoudre et expliquer.L'essentiel c'est que ça fonctionne sans accrocs.
6) faire l’installe d'un clic a partir de l’hébergement ? https://forum.pluxml.org/discussion/6213/kzinstall-pluxml-pret-en-quelques-secondes (KzInstall ) démontre que c'est simple et existe. J'utilise laragon depuis peu en local, et c'est d'un clique que je fait une install de la dernière version, à quand chez mon hébergeur ?. Peut-être proposé un partenariat avec un hébergeur pour qu'il l’intègre et le faire connaitre , de son coté PluXml pourrait servir de parrain , promouvoir cette hébergeur ... Si PluXml peut se doter d'un système de sauvegarde et de migration de la sauvegarde vers un site ou autre version a remettre en ligne, suite au dernier feu de joie, ce serait surement un bon argument ( l'utilisateur lambda aura du mal a copier son CMS sur une clé USB et ne sera pas quoi en faire par la suite) . Des script de migration de bdd vers pluxml ou vice-versa ont commencé à exister tôt dans l'histoire de PluXml.C'est à mon avis quelque chose qui manque pour que PluXml soit plus largement utilisé et éveille l’intérêt, une fois télécharger et lancer il ne faut plus longtemps pour totalement convaincre.
7) la page d'administration , entre 2007 et 2010 j'ai fait quelques installation de PluXml pour d'autre , famille , amis, restaurateur débutants, associations, ... , et à chaque fois, j'ai renommé et replacé ce répertoire ailleurs en laissant le répertoire core/admin comme leurre avec une page d'authentification en orbite sur password error! au premier submit ... pour éviter ce genre de désagrément (bah oui, je suis et resterait un éternel débutant dans le domaine du web ). Une option dans la config/install serait de pouvoir déterminé un nouveau répertoire pour l'administration. (j'avais bricolé un multi-blogs, en 2008, avec ce principe chaque blog greffé n'avait en gros que son propre répertoire admin et data. thèmes et tout le reste était unique (pas d’édition des thèmes dans l'admin à l'époque!) Les variable PLX_CORE et cie permettent ce genre de chose aisément.
8) l'edition des articles. Si le mode brouillon est un must pour démarrer un nouvel article, un mode similaire (entre l'article en ligne et celui en édition non validée) est cependant manquant. A l'occasion d'une mise à jour ou de complément d'un article déjà en ligne. Il est aisée de faire de simple correction et ajout sur un article en une seule passe, mais lorsqu'il s'agit de compléter profondément un article et de le faire sur des périodes plus longue que la durée de sessions, voir quelques jours selon la disponibilité du rédacteur, la seule option actuelle est de mettre l'article hors ligne avant de le ressortir.(peu avoir un impact sur le référencement)
Mes mods, plugs et bricoles étaient et sont d'abord pour le fun de les faire, ne vous trompez pas sur mon compte : Mon métier et ma formation : cap/bep puis il y a 10ans un bac+2 tout en restauration/hotellerie... pas d'options littéraire bien sur
Voilà c’était en vrac et un peu confus, je reviendrais dessus probablement. Bon Week-End
cdt,
GC
Bonjour,
Je suis utilisateur de PluXML depuis quelques temps, pas codeur, je m'intéresse à la modification / création de thème. J'ai beaucoup utilisé Drupal (4 à 7), ce qui oriente sans doute mon utilisation de PluXML, mais me fait aussi apprécier sa simplicité, sa légèreté et la facilité de sauvegarde.
Concernant les propositions:
Site / documentation en anglais: oui certainement
frawework php: visiblement abandonné, mais en tous cas, conserver la légereté de PluXML est certainement préserver sa différence
framework css: apprendre un framework "de plus" peut être une barrière. Laisser la liberté pour la partie front end est une très bonne chose. J'ai construit quelques sites avec Bootstrap (3 ou 4), j'ai utilisé le thème bs3 proposé pour PluXML (pour l'intégration d'un blog dans une autre site, bien pratique mais Bootstrap est lourd); j'ai regardé PluCSS (pour PluXML ou des sites "à la main) mais ai finalement choisi d'explorer w3.css. Peut-être une option pour la partie admin?
accessibilité: les pistes pour améliorer l'accessibilité sont aussi une très bonne chose (un autre plus pour PluXML)
XML: pourvoir lire son article / sa page directement dans un éditeur texte est un vrai plus (on peut récupérer facilement le contenu quoiqu'il arrive)
Merci pour tout ce travail, PluXML est un CMS qui j'apprécie énormément; bravo aux développeurs!
C'est dommage de partir sur Knacss v7, sachant que cette version n'est plus maintenue depuis 4 ans, et qu'elle ne sera plus mise à jour (c'est sur la home page). Peut-être serait-il judicieux de la monter en v8 à la place.
Pour ma culture personnelle, est-ce que l'utilisation simpleXML va aussi booster les performances de PluXML, ou bien est-ce que cela va surtout concerner les possibilités d'évolution de la structure des données ?
Knacss v8 n'était pas encore sortie quand j'ai commencé à migrer l'admin sur Knacss, mais oui avec la refonte du thème par défaut je vais regarder si on peut passer sur la v8.
Quant à simpleXML, je ne saurais dire si les performances seront boostées, mais ça va simplifier le code actuel, sa maintenance et son évolutivité.
Tu as le thème kzCleanlook qui utilise Knacss-reborn (ou v8.0).
Le code PHP est basé sur le thème "défaut" mais a été fortement factoriser pour éviter les redondances de code, notamment pour lister les articlesselon les catégories, les tags, les archives ou la homepage.
La prochaine version de kzCleanlook comprendra en plus des gabarits (template) pour pages statiques qui rendront caduques les plugins officiels plxMySearch et plxContact qui ne fonctionnent pas derrière un serveur Nginx.
Il y a(ura) également des gabarits pour des galeries images et des pages pour télécharger des fichiers avec urls 'cryptés'.
Concernant SimpleXml, j'aurais tendance à dire qu'il est plus rapide car il utilise moins de variables PHP et pas de boucle en PHP. Quant à dire que le gain de vitesse est perceptible, c'est moins évident car les fichiers XML dans le dossier datas ne sont pas très gros. Ce qui est sûr, c'est qu'on a un code PHP plus simple.
Le minimum requis pour les extensions par défaut sur un PluXml nu serait le moteur de recherche. Le formulaire de contact est un plus presque indispensable. feedback surveybreakfast hours
Réponses
Knacss est plus populaire que PluCss et plus simple. Et Knacss est bien soutenu par ses auteurs.
Le débat sur un framework CSS ne porte que sur le coté back-office de PluXml.
Côté thème, tu peux choisir le système de grille que tu veux ou pas. Avec les "display:grid" ou "display: flex", que ne supporte pas PluCss, les systèmes de grille présentent moins d'intérêt.
Qu'entends tu par les "security headers" ?
Pour les caches de plugins, ce n'est pas évident. Certains emploient des scripts JS, des feuilles CSS, des images. Et on peut ne pas les cacher. La seule chose à faire est de mettre la règle qui va bien dans un .htaccess pour empêcher d'appeler directement les fichiers .php. Et les fichiers .htaccess ne sont pas pris en compte par Nginx.
Si tu recherches du code PHP optimisé, il faut regarder directement la branche master sur le dépôt Github et tester.
On ne pourra avancer que lentement si peu de gens testent la prochaine version pour faire des remontées de bogues.
Pour la base de plugins mise à jour, c'est quasiment impossible. Cela prend beaucoup de temps. Par contre, ce qui manque c'est un système de notation pour les plugins et un dépôt centralisé des plugins "non officiels".
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Je n'avais pas fait bien attention à la proposition de thème par défaut ARIA et schema.org.
Je trouve que c'est une idée très intéressante.
Bonjour,
Pour Plucss, je trouve ça dommage, surtout pour les personnes qu'ils l'ont développé. Il suffirait peut-être d'y apporter les modifications
nécessaire pour qu'il satisfasse tout le monde. Et si Knacss décide d'arrêter ou de changer radicalement leur formule, faudra à nouveau tout réécrire.
Bref je trouve que c'est du détail ça par rapport à la structure même de Pluxml. Et du moment qu'on peut encore rajouter des class CSS à l'interface Admin, ça me va.
D'ailleurs le fait de pouvoir changer le nom du dossier Admin me parait être une bonne idée, c'est dèjà le cas sur d'autres platormes.
Pour les sécurity Headers, je me suis peut-être un peu emballé. je pense que développer un plugin officiel serait mieux.
Pour le Cache des plugins, oui c'est pas évident, puis il y a des déjà des plugins qu'il le font. C'est vrai que moi je parle de ça parce que
j'ai quelques sites sur les pages persos Free, et le htaccess, bah il y a pas grand chose qui passe avec. J'ai dû tout faire à la main.
Une autre chose c'est la fonction recherche intégrée, je trouve que c'est une bonne idée, même si ça va alourdir encore un peu code, il faudra pouvoir le désactiver si nécessaire.
J'ai eu une autre requête, c'est pour la page commentaires.php, il faudrait essayer d'externaliser le script de réponse aux commentaires.
Affaire à suivre
@+
Bonjour/bonsoir,
petit déterrage sur un sujet intéressant.
En vrac:
1) passer dans le monde Anglophone .
Ayant délaissé(4.1 la toute derniere version que j'avais télécharger ) PluXml durant une dizaine d'année , j'ai eté agreablement surpris de voir de l'anglais dans les pages du site mais aussi autant surpris qu'il n'ait pas un minimum pris dans les communauté anglophone. revenant sur PluXml pour redémarrer un projet (covid-19 à foutu un gros coup dans les relation sociales non virtuelles) Il m'a vite démange d'aller créer un nouveau tag sur stackoverflow.com (entre autre) et y poser mes quelques questions php et je me suis vite raviser. ce n'est pas mon rôle et cela demande probablement un peu plus de réflexions, expertise sur PluXml et aussi de disponibilités. Pour le coup je ne cochais aucune case.
2) PuxCss ou autre , tout dépend des utilisateurs. si des thèmes par défauts
- basé sur PluxCss, bootstrap , knacss, autre ou juste avec un reset classique et standard *(et puis sera t-il toujours nécessaire au vu des belles évolutions de nos navigateurs ces dernières années?)
- une structure minimale mais bien construite (structure html avec une sémantique pertinente et sa touche wai-aria)
sont proposée, chaque nouvelle utilisateur pourra démarrer a partir d'un thème par défaut et de ses framework qui lui parle et lui convient. ce qu'il faut c'est au moins un thème neutre, pas épuré ou minimaliste mais sans style qui permette simplement d'afficher le contenu.Perso , ce serait mon choix car je ne suis pas mal à l'aise avec les feuilles de styles et j'ai , comme beaucoup d'autres, mes opinions sur tel ou tel framework. Mais un devops, qui veut se faire son petit blog pour communiquer auprès d'un public restreint se contenteras d'un thème par défaut, d'un bootsrap et d'un des thémes de bootstrap. Ce sera un utilisateur satisfait et aussi un ambassadeur malgré lui
Quand on jette un oeil sur des projets en react par exemple, on comprend tout de suite que le gars qui veut faire un truc simple vite fait ne vas pas se recoltiner un PluxCss quant il a éventuellement l'habitude d'un bootstrap pour injecter ses styles.
3) simpleXml ... oui, lorsque que j'ai découvert pluxml a ses début, c'est ce que je me suis demandé, pourquoi non ? Dix ans plus tard, des portions du code de PluXml me sont toujours familière et semble inchangée.(a part le thème initialement composé d'un unique fichier : template.php breakant sur le mode en cours... et le nombre de fichier de class qui ont fait des petits
) 
. Non, Gardons cette French-touch 
Sans être développeur, certaine partie du code semble vraiment redondante mais traitant des fichiers de structures différentes . Pourquoi pas, mais alors pourquoi ne pas en faire une spécificité en réduisant ces fonctions similaires en une seule , plutôt que de reprendre d'autres scripts dont on va faire un assemblage et renommé PluXml? PluxJson pourrait aussi prendre la releve aprés tout
Au début j'ai naïvement pensé que l'Xml était un atout dans le sens ou de nombreux autres logiciels en faisait usage et je voyais le blog communiquer et se transformer aisément en pdf, ebook, fichier word ou openOffice et vice versa, mais non, un fichier .ini, .txt ou . csv aurait tout autant fait l'affaire au début .(c’était aussi les belles heures de XHTML ) .
4) la retro compatibilité, cela a toujours posée quelques soucis , mais des plugins d'exportations du contenu et de la config d'une version x vers une version plus récente à chaque modifs majeure pourrait suffire. à propos , un update d'une version 3 a la version 5.8.6 (~2009 =>2020), personne n'as ? NaN , je rigole. Pour les plugins ? Oui, effectivement, les plugins les plus utiliser et aboutie devrait mériter de devenir partie intégrante de PluXml et rejoindre ces fichiers class.plxmachin.php . Liste qui s’étoffe depuis les débuts de PluXml.
Perso, en 2008 j’avais en base un formulaire de mail/contact(static), un site map(static), googlemap(static), un plug gallerie tri et légende, un éditeur simple avec en sus une petite table de caractére HTML et son popup en preview(live ou pas dans le thème en cours) avec l'insertion d'un template dédier au thème(initialement mis en place pour ma sœur et ensuite customiser pour les autres), le plugin user et des répertoires médias distinct par user, Ckeditor avait toute ma sympathie( mais faisais beaucoup grossir l'archive), ... bref, aujourd'hui beaucoup de ses choses ne nécessite plus de greffons et c'est super.
5)Oui PluXml est facile d'utilisation et accessible aux débutants et j'espère que cela restera ainsi. C'est pour beaucoup sa marque de fabrique et surement l'une de ses qualités.Une courbe d'apprentissage courte est un atout et une demande réel aujourd'hui (quel que soit le domaine). tout le monde imagine qu'un clique et une feuille de calcul peuvent tout résoudre et expliquer.L'essentiel c'est que ça fonctionne sans accrocs.
6) faire l’installe d'un clic a partir de l’hébergement ? https://forum.pluxml.org/discussion/6213/kzinstall-pluxml-pret-en-quelques-secondes (KzInstall ) démontre que c'est simple et existe. J'utilise laragon depuis peu en local, et c'est d'un clique que je fait une install de la dernière version, à quand chez mon hébergeur ?. Peut-être proposé un partenariat avec un hébergeur pour qu'il l’intègre et le faire connaitre , de son coté PluXml pourrait servir de parrain , promouvoir cette hébergeur ... Si PluXml peut se doter d'un système de sauvegarde et de migration de la sauvegarde vers un site ou autre version a remettre en ligne, suite au dernier feu de joie, ce serait surement un bon argument ( l'utilisateur lambda aura du mal a copier son CMS sur une clé USB et ne sera pas quoi en faire par la suite) . Des script de migration de bdd vers pluxml ou vice-versa ont commencé à exister tôt dans l'histoire de PluXml.C'est à mon avis quelque chose qui manque pour que PluXml soit plus largement utilisé et éveille l’intérêt, une fois télécharger et lancer il ne faut plus longtemps pour totalement convaincre.
7) la page d'administration , entre 2007 et 2010 j'ai fait quelques installation de PluXml pour d'autre , famille , amis, restaurateur débutants, associations, ... , et à chaque fois, j'ai renommé et replacé ce répertoire ailleurs en laissant le répertoire core/admin comme leurre avec une page d'authentification en orbite sur password error! au premier submit ... pour éviter ce genre de désagrément (bah oui, je suis et resterait un éternel débutant dans le domaine du web ). Une option dans la config/install serait de pouvoir déterminé un nouveau répertoire pour l'administration. (j'avais bricolé un multi-blogs, en 2008, avec ce principe chaque blog greffé n'avait en gros que son propre répertoire admin et data. thèmes et tout le reste était unique (pas d’édition des thèmes dans l'admin à l'époque!) Les variable PLX_CORE et cie permettent ce genre de chose aisément.
8) l'edition des articles. Si le mode brouillon est un must pour démarrer un nouvel article, un mode similaire (entre l'article en ligne et celui en édition non validée) est cependant manquant. A l'occasion d'une mise à jour ou de complément d'un article déjà en ligne. Il est aisée de faire de simple correction et ajout sur un article en une seule passe, mais lorsqu'il s'agit de compléter profondément un article et de le faire sur des périodes plus longue que la durée de sessions, voir quelques jours selon la disponibilité du rédacteur, la seule option actuelle est de mettre l'article hors ligne avant de le ressortir.(peu avoir un impact sur le référencement)
Mes mods, plugs et bricoles étaient et sont d'abord pour le fun de les faire, ne vous trompez pas sur mon compte : Mon métier et ma formation : cap/bep puis il y a 10ans un bac+2 tout en restauration/hotellerie... pas d'options littéraire bien sur
Voilà c’était en vrac et un peu confus, je reviendrais dessus probablement. Bon Week-End
cdt,
GC
Cordialement,
gcyrillus
Mon site PluXml: https://re7net.com | Plugins: https://ressources.pluxopolis.net/banque-plugins/index.php?all_versions | demos sur free http://gcyrillus.free.fr/new | Thèmes: tester et télécharger @ https://pluxthemes.com
Indiquez [RESOLU] dans le titre de votre question une fois le soucis réglè, Merci
Bonjour,
Je suis utilisateur de PluXML depuis quelques temps, pas codeur, je m'intéresse à la modification / création de thème. J'ai beaucoup utilisé Drupal (4 à 7), ce qui oriente sans doute mon utilisation de PluXML, mais me fait aussi apprécier sa simplicité, sa légèreté et la facilité de sauvegarde.
Concernant les propositions:
Merci pour tout ce travail, PluXML est un CMS qui j'apprécie énormément; bravo aux développeurs!
Bonjour,
La prochaine version de PluXml (6.0.0) utilisera le framework CSS Knacss version 7.0 côté admin.
https://www.knacss.com/doc-old.html
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
petite remarque perso
" - sur les pages correspondant aux " tags " :
title is missing / description is missing "
mes sites principaux : fonds d'écran gratuits - longue traîne - référencer votre site - brocante en ligne -
C'est dommage de partir sur Knacss v7, sachant que cette version n'est plus maintenue depuis 4 ans, et qu'elle ne sera plus mise à jour (c'est sur la home page). Peut-être serait-il judicieux de la monter en v8 à la place.
Pour ma culture personnelle, est-ce que l'utilisation simpleXML va aussi booster les performances de PluXML, ou bien est-ce que cela va surtout concerner les possibilités d'évolution de la structure des données ?
Knacss v8 n'était pas encore sortie quand j'ai commencé à migrer l'admin sur Knacss, mais oui avec la refonte du thème par défaut je vais regarder si on peut passer sur la v8.
Quant à simpleXML, je ne saurais dire si les performances seront boostées, mais ça va simplifier le code actuel, sa maintenance et son évolutivité.
@PPmarcel ,
Tu as le thème kzCleanlook qui utilise Knacss-reborn (ou v8.0).
Le code PHP est basé sur le thème "défaut" mais a été fortement factoriser pour éviter les redondances de code, notamment pour lister les articlesselon les catégories, les tags, les archives ou la homepage.
La prochaine version de kzCleanlook comprendra en plus des gabarits (template) pour pages statiques qui rendront caduques les plugins officiels plxMySearch et plxContact qui ne fonctionnent pas derrière un serveur Nginx.
Il y a(ura) également des gabarits pour des galeries images et des pages pour télécharger des fichiers avec urls 'cryptés'.
Concernant SimpleXml, j'aurais tendance à dire qu'il est plus rapide car il utilise moins de variables PHP et pas de boucle en PHP. Quant à dire que le gain de vitesse est perceptible, c'est moins évident car les fichiers XML dans le dossier datas ne sont pas très gros. Ce qui est sûr, c'est qu'on a un code PHP plus simple.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Le minimum requis pour les extensions par défaut sur un PluXml nu serait le moteur de recherche. Le formulaire de contact est un plus presque indispensable. feedback survey breakfast hours