Ça dépend des variables utilisées dans la fonction des derniers articles (probablement lastArtList) et possiblement d'une petite faute d'orthographe quelque part. Tu peux nous donner une copie de la fonction complète et on verra vite ce qui cloche. Quelques variables ont été ajoutées mais elles n'affectent pas celles qui y étaient déjà.
Et c'est normal qu'une interruption causée par une structure php non conforme arrête complètement l'affichage et empêche le footer d'être visible. Tout ça va rentrer dans l'ordre quand on retouchera la fonction des articles.
@Stéphane: Je pense qu'on a un problème de version dans le master sur github.
Les trois variables mentionnées pour l'image d'article ne sont pas dans lastArtList. Je roulais par erreur avec une copie où j'avais collé ma suggestion décrite plus haut. La version sur le github utilise une gymnastique interne de artThumbnail mais les trois variables ne sont pas là à l'état brut comme dans mon post #102. Ça explique peut-être le message d'erreur vécu par Dudy.
Mise à jour: pour des raisons que je ne peux expliquer, les deux méthodes produisent le bon résultat à l'intérieur de lastArtList... la gymnastique a l'air de fonctionner.
je crois que tu as raison, j'ai échangé le fichier class.plx.show.php, avec la version [del]précédent[/del]anterieur et tout est en ordre pas de message d'erreur
Je m'inquièterais si c'était en reprenant une version antérieure que tout fonctionne. Il est certainement préférable de voir ce qui cloche en utilisant la version officielle, donc la dernière dans le master.
Si tu nous donnes une copie de ta fonction lastArtList avec son contenu, ça ira sans doute très vite pour rectifier la situation de l'affichage.
@Pierre
la version est celle depuis le lien qui donne Stéphane ( #119 ), je n'ai rien changé,
sur un Pluxml tout vierge avec le thème Defaut juste avec un article et une page statique habituel
La fonction artThumbnail n'est pas du tout celle dont nous parlions, celle-ci fonctionne depuis longtemps et n'a pas été modifiée. Mon intervention et la modification effectuée par Stèphane touche les variables utilisées à l'intérieur du format de lastArtList. Elles sont tirées de artThumbnail mais sont à l'intérieur de lastArtList.
Ainsi, ce qu'il faudra pour expliquer ton problème d'affichage c'est la fonction dans TA page, où ça dit lastArtList('quelquechose') ou possiblement artThumbnail('quelquechose'). Il nous faut ton contenu pour le réparer, pas celui de la fonction. Tu peux nous donner toute la sidebar si tu veux.
Oh oh, je viens de réinstaller tout et j'ai la même chose, mes excuses. Je regarde si je peux aider.
Mise à jour: J'ai plus de questions que de réponses... Tout allait si bien et maintenant, mes quelques lignes suggérées ne fonctionnent plus non plus...
L'emploi de la constante PLX_ROOT m'a toujours laissé perplexe.
Selon les cas, sa valeur est égale à './' ou '../../'. Et on retrouve ces valeurs dans le source des pages générées et cela ne me semble pas très professionnel.
Autre souci: PLX_ROOT est utilisé soit pour le système de fichiers sur le serveur, soit dans les adresses url (link, script, href, src, ...). En somme, un mélange des genres.
Si on fait quelques "grep PLX_ROOT core/admin/*.php", "grep PLX_ROOT core/lib/*.php", "grep PLX_ROOT *.php", à la racine du site, on s'aperçoit que dans environ 80% des cas PLX_ROOT est utilisé avec le système de fichiers.
Dans ce cas une façon simple de supprimer ces horribles './' ou '../../' est de définir la constante PLX_ROOT dans le fichier config.php à la racine du site comme ceci :
C'est aussi un excellent endroit pour définir 2 nouvelles constantes PLX_LIB et PLX_ROOT qu'on peut employer pour tous les "include" utilisés dans les fichiers .php.
L'idée sous-jacente étant d'avoir la possibilité de renommer les dossiers core/lib et core/admin pour se cacher des bad boys qui trainent sur le net.
Concernant l'emploi de PLX_ROOT dans les urls, il serait plus efficace d'avoir recours à $plxAdmin->racine, $plxShow->plxMotor->racine, voire plxUtils::getRacine()
J'ai envoyé un pull request (plx_core) qui corrige la béta 3 de Pluxml pour les différents fichiers php à la racine du site et dans les dossiers core/lib/ et core/admin/.
Bonjour, pour info dans la dernière 5.5 il y a un problème d'encodage dans la langue espagnole côté admin, les caractères sont mal affichés (pas le cas dans la 5.4), rien de méchant, le fichier admin.php dans core->lang->es a été sauvé en ANSI d'où le problème à l'affichage, une simple conversion en UTF-8 sans BOM a résolu le problème (les autres fichiers du répertoire sont d'ailleurs bien en UTF-8 sans BOM).
Je n'ai pas vérifié si le problème existe sur d'autres langues (seulement testé français anglais espagnol).
Bonjour, pour info dans la dernière 5.5 il y a un problème d'encodage dans la langue espagnole côté admin, les caractères sont mal affichés (pas le cas dans la 5.4), rien de méchant, le fichier admin.php dans core->lang->es a été sauvé en ANSI d'où le problème à l'affichage, une simple conversion en UTF-8 sans BOM a résolu le problème (les autres fichiers du répertoire sont d'ailleurs bien en UTF-8 sans BOM).
Je n'ai pas vérifié si le problème existe sur d'autres langues (seulement testé français anglais espagnol).
ha ou bien vu ! j'ai mis à jour le format de fichier sur github
pour les autres langues ça semble ok
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
@bazooka07:
C'est très intéressant tes modifs. ça me plait bien.
J'hésite à valider ton pull-request pour le moment car il y beaucoup de modifs et ça demande des tests de non régression. En ce moment en période de béta ça remet en cause tout le planning et les prévisions de sorties de la 5.5
En regardant rapidement tes modifs, je vois une première chose qui ne va pas. Exemple: tu as rajouté des constantes dans le fichier config.php. Or ce fichier est modifié dynamiquement quand tu changes la valeur du dossier data/configuration/ sur l'écran de config où tu peux paramétrer tous les chemins des dossiers (Configuration avancée > Emplacement des fichiers de configuration). En modifiant cette valeur le fichier config.php est écrasé et on perdra les 3 define que tu as rajouté dedans.
Faut donc que j'analyse ce que tu proposes, d'autant plus que ce n'est pas que remplacement, j'ai vu que tu as déplacé des lignes de code, changé la valeur de PLX_ADMIN (voir effet de bords sur les plugins, si impact), etc...
A suivre donc... et merci pour ce travail.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
@bazooka07:
je te donne un exemple d'effet de bord que je vois en ayant déplacer la constante PLX_ADMIN dans le fichier config.php
Actuellement PLX_ADMIN est défini dans le fichier class.plx.admin.php
Ce fichier n'est chargé que quand on est dans l'admin.
Pour savoir si on est dans l'admin, le test if(defined('PLX_ADMIN')) suffit (indépendamment de la valeur que contient PLX_ADMIN)
En déplaçant PLX_ADMIN dans config.php qui est chargé coté front-end et back-end on ne peut plus savoir où on est.
Ce test est utilisé dans des plugins par exemple. Donc là, cette modif pose un problème.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je n'avais pas noté que config.php pouvait être modifié "à la volée" dans le panneau de config. Ce n'est pas un gros souci. Je vais corriger la fonction plxAdmin::editConfiguration qui génère ce fichier.
J'ai hésité à ré-employer la constante PLX_ADMIN. Mais son usage actuel ne me semble pas pertinent pour plusieurs raisons.
On se moque complètement de sa valeur
Pour tester si on est dans la partie admin, il y a d'autres solutions :
[== Indéfini ==]
<?php
if (isset($plxAdmin)) {...}
if (class_exists('plxAdmin')) {...}
?>
J'utilise couramment la 1ère solution dans tous les plugins que j'ai travaillé pour connaitre l'url de base du plugin. Je ne sais pas s'il existe des plugins qui utilisent déjà cette constante. Mais cela est facile de donner un nouveau nom à cette constante et de recréer la constante initiale.
Il n'y a pas tant de modifs que cela, du moins à mon niveau. Le plus compliqué a été de comprendre comment marcher plxMedias.
Laisse moi 48 heures pour corriger cela et je t'envoie un autre pull request.
Pour la sortie de Pluxml 5.5, cela me parait prématurer :
J'ai un autre pull request en attente pour transformer les urls type "/article54/la-cueillette_des mirabelles" en "/article/la_cueillette_des_mirabelles". Idem pour les pages statiques et le catégories. avec correction dans les flux RSS et le sitemap. Pour les tags et les archives cela existe déjà. Cela fait un moment qu'on le réclame. Et au final, ce n'est pas très compliqué.
Il y aussi toutes les expressions régulières à améliorer et qui ne filtrent pas de façon assez stricte. Ce serait l'occasion d'ajouter une catégorie pour épingler des articles. J'ai fait la modif pour Pluxml 5.4. Et cela m'ennuie de faire la modif à chaque version.
@bazooka07 tout ce que tu proposes m’intéressent énormément. et je serais d'avis de réserver tout ça pour la version suivante de PluXml. il a déjà eu pas mal d'évolution sur la 5.5, et du coup se faire une 5.6 dédiée avec tout ce que as fait me semble beaucoup plus adapté. Je n'ai pas envie de précipiter les choses par rapport à la 5.5. Je comprends ton enthousiasme et je le partage car toutes tes modifs sont très profitables. Un des axes d'améliorations que je me suis fixé pour la 5.6 et l'optimisation et les performances et du coup tout ce que tu as fait rentre pile poile la dedans. On sait par exemple que la sidebar est consommatrice de ressources, on est limité à 9999 articles (à cause des regex) j'aimerais passer cette limite à 99999, il faudrait revoir la gestion des regex pour avoir une sorte de dictionnaire de référence pour éviter d'avoir des regex partout de le code (souvent codé différemment pour le même résultat). Je partage mes réflexions qui ne sont pas pour le moment abouties mais il y a encore moyen de faire des optimisations techniques. Prends le temps qu'il te faut.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je suis en train de tester la beta super boulo bravo
Petite interrogation, lors de la mise à jour du site en 5.5, ne serait-til pas judicieux de proposer une copie des liens images de vignette au nouveau système de pluxml ?
tu peux utiliser maintenant #img_url, #img_title, #img_alt dans lastArtList en + de #art_thumbnail
Ça va telllllllement bien! T'as pas idée.
J'ai déjà hâte de convertir mon premier thème en 5.5 avec la mention marketing "aucun plugin nécessaire". [del]J'espère que le thème aura pas de page contact ou d'outil de recherche [/del] (insérer GROS CLIN D'OEIL ici!).
Bravo en attendant.
J'avais pas vu le fil de la discussion....en effet, Heureusement que Stephane a intégré ça, j'utilise aussi énormément cette fonctionnalité!!!(ex: http://cfdev.fr/#webdesign)
@Stephane:
Suite à tes remarques, j'ai rétabli la constante initiale PLX_ADMIN.
Les variables que j'ai créé PLX_LIB et PLX_ADMIN sont renommées en PLX_LIB_PATH et PLX_ADMIN_PATH. Par convention, on considère que les constantes PLX_xxxx_PATH sont des adresses relatives et finissent par '/'. (Je ne suis pas sûr que cela soit dans le manuel du développeur.)
J'ai corrigé la fonction plxAdmin::editconfiguration() qui génére le fichier config.php. En aparté, modifier la valeur de "Emplacement des fichiers de configuration" est hors de portée d'un newbie et oblique à quelque intervention manuelle dans les fichiers et répertoires.
Comme PLX_ROOT, et par voie de conséquence PLX_PLUGINS deviennent des adresses absolues, l'usage de la fonction realpath() n'est plus nécessaire.
J'ai corrigé quelques bugs au passage :
dans plxUtils::getRacine(), on utilise la chaine de caractères 'plugins' qui fait référence à un dossier. C'est un bug car l'administrateur peut changer le dossier des plugins dans le panneau de config.
Dans le thème par défaut, l'accès au back-office est inscrit en dur dans le fichier footer.php avec la chaine 'core/admin/'. Cela bloque toute évolution de Pluxml. Il vaut mieux utiliser une fonction de $plxShow à créer ou renvoyer vers le fichier index.php en passant un paramètre. C'est cette option que j'ai choisi avec un lien du type <a rel="no-follow" href="index.php?signin" />
(Pour les nuls en anglais, "signin= s'identifier")
J'ai optimisé également la fonction listFolderFiles() dans core/admin/parametres_edittpl.php. En effet, l'utilisation de glob() est plus performante que scandir()
Avec toutes ces modifs, on peut maintenant renommer les dossiers core/admin et core/lib en core/artistes et core/engine par exemple. Il n'est pas nécessaire que les 2 dossiers partagent un dossier commun. Cela complète la possibilité de renommer le dossier plugins en kaissahoutils par exemple.
Les bad boys du net vont perdre leurs chemins
Il est dommage que le dossier lang ne soit pas intégré dans le dossier core/lib pour modifier son chemin d'accès.
Une remarque à part. :
le serveur Nginx est de plus en plus populaire. Il est plus rapide et plus léger que Apache. il est au top pour ceux qui font de l'auto-hébergement sur une petite config comme un Raspberry.
Il fait proxy en renvoyant des fichiers images ou texte, y compris des fichiers .js ou min.js. Cela serait bien de regrouper tous ces fichiers dans un dossier. En effet, dans la config de Nginx, on peut utiliser des règles pour ces fichiers sans passer par des expressions régulières type '*\.txt$" ce qui est beaucoup plus rapide.
Pour les prochaines versions, ce serait bien de proposer à l'installation la possibilité de renommer les dossiers core/admin, core/lib et data.
Je t'ai envoyé un nouveau pull request sur la branche plx_root pour toutes ces modifs.
Pluxml regarde s'il existe une fonction onActivate ou OnDeactivate pour le plugin. AMHA, il manque une fonction OnDelete. En effet, certains plugins ont besoin de créer un dossier ou un fichier, qui ne sont pas forcément dans le dossier du plugin (Pb droit en écriture), selon la configuration demandée par l'utilisateur. Quand on supprime le plugin, ces fichiers/dossiers restent.
Les plugins peuvent être installés à la main sans passer par Pluxml, avec des droits en écriture pour l'administrateur du serveur différents des droits accordés au serveur web (typiquement www-data sur Debian et Ubuntu)
Quand on veut supprimer un plugin, Pluxml tente d'abord de supprimer le dossier du plugin. Si ça plante, on arrrête le processus et les fichiers de config et feuilles de style restent en l'état dans le dossier data/configuration.
Dans la fonction plxPlugins::saveConfig(..), il me semble logique de faire dans l'ordre : suppression des feuilles de style, suppression du paramétrage du plugin, mise à jour du fichier data/configuration/plugins.xml et enfin suppression du dossier du plugin dans le dossier plugins.
Hélas, actuellement on procède exactement dans l'ordre inverse.
Quand l'administrateur du serveur veut faire une mise à jour propre, il se retrouve avec les anciennes feuilles de style et l'ancienne config du plugin.
Sur une install en mise à jour de la 5.4 :
Le chargement d'image à partir du plugin plxeditor 1.4.1 ne fonctionne pas.
La validation est faite mais l'image n'apparait pas et n'est pas envoyée sur le serveur.
Le captcha du formulaire de contact du plugin MyContact ne fonctionne pas mais fonctionne bien dans les commentaires.
Sur une installation neuve :
Le formulaire d'envoi d'image du plugin plxeditor ne fonctionne pas non plus.
Pluxml regarde s'il existe une fonction onActivate ou OnDeactivate pour le plugin. AMHA, il manque une fonction OnDelete. En effet, certains plugins ont besoin de créer un dossier ou un fichier, qui ne sont pas forcément dans le dossier du plugin (Pb droit en écriture), selon la configuration demandée par l'utilisateur. Quand on supprime le plugin, ces fichiers/dossiers restent.
Les plugins peuvent être installés à la main sans passer par Pluxml, avec des droits en écriture pour l'administrateur du serveur différents des droits accordés au serveur web (typiquement www-data sur Debian et Ubuntu)
Quand on veut supprimer un plugin, Pluxml tente d'abord de supprimer le dossier du plugin. Si ça plante, on arrrête le processus et les fichiers de config et feuilles de style restent en l'état dans le dossier data/configuration.
Dans la fonction plxPlugins::saveConfig(..), il me semble logique de faire dans l'ordre : suppression des feuilles de style, suppression du paramétrage du plugin, mise à jour du fichier data/configuration/plugins.xml et enfin suppression du dossier du plugin dans le dossier plugins.
Hélas, actuellement on procède exactement dans l'ordre inverse.
Quand l'administrateur du serveur veut faire une mise à jour propre, il se retrouve avec les anciennes feuilles de style et l'ancienne config du plugin.
Sur une install en mise à jour de la 5.4 :
Le chargement d'image à partir du plugin plxeditor 1.4.1 ne fonctionne pas.
La validation est faite mais l'image n'apparait pas et n'est pas envoyée sur le serveur.
Le captcha du formulaire de contact du plugin MyContact ne fonctionne pas mais fonctionne bien dans les commentaires.
Sur une installation neuve :
Le formulaire d'envoi d'image du plugin plxeditor ne fonctionne pas non plus.
5.4 ou 5.5 ?
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Quand on active l'inspecteur du navigateur pour le popup des médias, on voit bien une belle collection d'erreurs 404.
On a déménagé les scripts javascript dans la nouvelle version de Pluxml mais l'intendance ne suit pas, en bref.
Il faut faire une mise à jour dans le plugin pour le fichier medias.php.
Evitons de réinventer la roue et utilisons le gestionnaire de médias core/medias.php de Pluxml pour suivre ses évolutions
Cela marche très bien dans d'autres plugins
Réponses
Et c'est normal qu'une interruption causée par une structure php non conforme arrête complètement l'affichage et empêche le footer d'être visible. Tout ça va rentrer dans l'ordre quand on retouchera la fonction des articles.
Les trois variables mentionnées pour l'image d'article ne sont pas dans lastArtList. Je roulais par erreur avec une copie où j'avais collé ma suggestion décrite plus haut. La version sur le github utilise une gymnastique interne de artThumbnail mais les trois variables ne sont pas là à l'état brut comme dans mon post #102. Ça explique peut-être le message d'erreur vécu par Dudy.
Mise à jour: pour des raisons que je ne peux expliquer, les deux méthodes produisent le bon résultat à l'intérieur de lastArtList... la gymnastique a l'air de fonctionner.
je crois que tu as raison, j'ai échangé le fichier class.plx.show.php, avec la version [del]précédent[/del]anterieur et tout est en ordre pas de message d'erreur
bonne continuation
Si tu nous donnes une copie de ta fonction lastArtList avec son contenu, ça ira sans doute très vite pour rectifier la situation de l'affichage.
la version est celle depuis le lien qui donne Stéphane ( #119 ), je n'ai rien changé,
sur un Pluxml tout vierge avec le thème Defaut juste avec un article et une page statique habituel
rien de compliqué
script fichier class.plx.show.php dernière lien donné par Stephane sur Github script fichier class.plx.show.php anterieur
Ainsi, ce qu'il faudra pour expliquer ton problème d'affichage c'est la fonction dans TA page, où ça dit lastArtList('quelquechose') ou possiblement artThumbnail('quelquechose'). Il nous faut ton contenu pour le réparer, pas celui de la fonction. Tu peux nous donner toute la sidebar si tu veux.
Mise à jour: J'ai plus de questions que de réponses... Tout allait si bien et maintenant, mes quelques lignes suggérées ne fonctionnent plus non plus...
merci Pierre nous sommes 2 a ne pas comprendre
Oui
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
https://github.com/pluxml/PluXml/releases/tag/5.5-beta-3
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Edit : oui il a de nouvelles chaînes, traduites sur le Git mais ce n'est pas comme ça qu'on le dirait en occitan du Languedoc du moins ^^ On dit "respondre", c'est une forme gasconne et provençale comme écrit sur le Git.
Stéphane, je te ferai passer un nouveau fichier.
Selon les cas, sa valeur est égale à './' ou '../../'. Et on retrouve ces valeurs dans le source des pages générées et cela ne me semble pas très professionnel.
Autre souci: PLX_ROOT est utilisé soit pour le système de fichiers sur le serveur, soit dans les adresses url (link, script, href, src, ...). En somme, un mélange des genres.
Si on fait quelques "grep PLX_ROOT core/admin/*.php", "grep PLX_ROOT core/lib/*.php", "grep PLX_ROOT *.php", à la racine du site, on s'aperçoit que dans environ 80% des cas PLX_ROOT est utilisé avec le système de fichiers.
Dans ce cas une façon simple de supprimer ces horribles './' ou '../../' est de définir la constante PLX_ROOT dans le fichier config.php à la racine du site comme ceci :
C'est aussi un excellent endroit pour définir 2 nouvelles constantes PLX_LIB et PLX_ROOT qu'on peut employer pour tous les "include" utilisés dans les fichiers .php.
L'idée sous-jacente étant d'avoir la possibilité de renommer les dossiers core/lib et core/admin pour se cacher des bad boys qui trainent sur le net.
Concernant l'emploi de PLX_ROOT dans les urls, il serait plus efficace d'avoir recours à $plxAdmin->racine, $plxShow->plxMotor->racine, voire plxUtils::getRacine()
J'ai envoyé un pull request (plx_core) qui corrige la béta 3 de Pluxml pour les différents fichiers php à la racine du site et dans les dossiers core/lib/ et core/admin/.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Je n'ai pas vérifié si le problème existe sur d'autres langues (seulement testé français anglais espagnol).
Pierre Aribaut - zetrader & zeforums
ha ou bien vu ! j'ai mis à jour le format de fichier sur github
pour les autres langues ça semble ok
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
C'est très intéressant tes modifs. ça me plait bien.
J'hésite à valider ton pull-request pour le moment car il y beaucoup de modifs et ça demande des tests de non régression. En ce moment en période de béta ça remet en cause tout le planning et les prévisions de sorties de la 5.5
En regardant rapidement tes modifs, je vois une première chose qui ne va pas. Exemple: tu as rajouté des constantes dans le fichier config.php. Or ce fichier est modifié dynamiquement quand tu changes la valeur du dossier data/configuration/ sur l'écran de config où tu peux paramétrer tous les chemins des dossiers (Configuration avancée > Emplacement des fichiers de configuration). En modifiant cette valeur le fichier config.php est écrasé et on perdra les 3 define que tu as rajouté dedans.
Faut donc que j'analyse ce que tu proposes, d'autant plus que ce n'est pas que remplacement, j'ai vu que tu as déplacé des lignes de code, changé la valeur de PLX_ADMIN (voir effet de bords sur les plugins, si impact), etc...
A suivre donc... et merci pour ce travail.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
je te donne un exemple d'effet de bord que je vois en ayant déplacer la constante PLX_ADMIN dans le fichier config.php
Actuellement PLX_ADMIN est défini dans le fichier class.plx.admin.php
Ce fichier n'est chargé que quand on est dans l'admin.
Pour savoir si on est dans l'admin, le test if(defined('PLX_ADMIN')) suffit (indépendamment de la valeur que contient PLX_ADMIN)
En déplaçant PLX_ADMIN dans config.php qui est chargé coté front-end et back-end on ne peut plus savoir où on est.
Ce test est utilisé dans des plugins par exemple. Donc là, cette modif pose un problème.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je n'avais pas noté que config.php pouvait être modifié "à la volée" dans le panneau de config. Ce n'est pas un gros souci. Je vais corriger la fonction plxAdmin::editConfiguration qui génère ce fichier.
J'ai hésité à ré-employer la constante PLX_ADMIN. Mais son usage actuel ne me semble pas pertinent pour plusieurs raisons.
On se moque complètement de sa valeur
Pour tester si on est dans la partie admin, il y a d'autres solutions : J'utilise couramment la 1ère solution dans tous les plugins que j'ai travaillé pour connaitre l'url de base du plugin. Je ne sais pas s'il existe des plugins qui utilisent déjà cette constante. Mais cela est facile de donner un nouveau nom à cette constante et de recréer la constante initiale.
Il n'y a pas tant de modifs que cela, du moins à mon niveau. Le plus compliqué a été de comprendre comment marcher plxMedias.
Laisse moi 48 heures pour corriger cela et je t'envoie un autre pull request.
Pour la sortie de Pluxml 5.5, cela me parait prématurer :
J'ai un autre pull request en attente pour transformer les urls type "/article54/la-cueillette_des mirabelles" en "/article/la_cueillette_des_mirabelles". Idem pour les pages statiques et le catégories. avec correction dans les flux RSS et le sitemap. Pour les tags et les archives cela existe déjà. Cela fait un moment qu'on le réclame. Et au final, ce n'est pas très compliqué.
Il y aussi toutes les expressions régulières à améliorer et qui ne filtrent pas de façon assez stricte. Ce serait l'occasion d'ajouter une catégorie pour épingler des articles. J'ai fait la modif pour Pluxml 5.4. Et cela m'ennuie de faire la modif à chaque version.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Petite interrogation, lors de la mise à jour du site en 5.5, ne serait-til pas judicieux de proposer une copie des liens images de vignette au nouveau système de pluxml ?
J'avais pas vu le fil de la discussion....en effet, Heureusement que Stephane a intégré ça, j'utilise aussi énormément cette fonctionnalité!!!(ex: http://cfdev.fr/#webdesign)
@Stephane:
Suite à tes remarques, j'ai rétabli la constante initiale PLX_ADMIN.
Les variables que j'ai créé PLX_LIB et PLX_ADMIN sont renommées en PLX_LIB_PATH et PLX_ADMIN_PATH. Par convention, on considère que les constantes PLX_xxxx_PATH sont des adresses relatives et finissent par '/'. (Je ne suis pas sûr que cela soit dans le manuel du développeur.)
J'ai corrigé la fonction plxAdmin::editconfiguration() qui génére le fichier config.php. En aparté, modifier la valeur de "Emplacement des fichiers de configuration" est hors de portée d'un newbie et oblique à quelque intervention manuelle dans les fichiers et répertoires.
Comme PLX_ROOT, et par voie de conséquence PLX_PLUGINS deviennent des adresses absolues, l'usage de la fonction realpath() n'est plus nécessaire.
J'ai corrigé quelques bugs au passage :
dans plxUtils::getRacine(), on utilise la chaine de caractères 'plugins' qui fait référence à un dossier. C'est un bug car l'administrateur peut changer le dossier des plugins dans le panneau de config.
Dans le thème par défaut, l'accès au back-office est inscrit en dur dans le fichier footer.php avec la chaine 'core/admin/'. Cela bloque toute évolution de Pluxml. Il vaut mieux utiliser une fonction de $plxShow à créer ou renvoyer vers le fichier index.php en passant un paramètre. C'est cette option que j'ai choisi avec un lien du type <a rel="no-follow" href="index.php?signin" />
(Pour les nuls en anglais, "signin= s'identifier")
J'ai optimisé également la fonction listFolderFiles() dans core/admin/parametres_edittpl.php. En effet, l'utilisation de glob() est plus performante que scandir()
Avec toutes ces modifs, on peut maintenant renommer les dossiers core/admin et core/lib en core/artistes et core/engine par exemple. Il n'est pas nécessaire que les 2 dossiers partagent un dossier commun. Cela complète la possibilité de renommer le dossier plugins en kaissahoutils par exemple.
Les bad boys du net vont perdre leurs chemins
Il est dommage que le dossier lang ne soit pas intégré dans le dossier core/lib pour modifier son chemin d'accès.
Une remarque à part. :
le serveur Nginx est de plus en plus populaire. Il est plus rapide et plus léger que Apache. il est au top pour ceux qui font de l'auto-hébergement sur une petite config comme un Raspberry.
Il fait proxy en renvoyant des fichiers images ou texte, y compris des fichiers .js ou min.js. Cela serait bien de regrouper tous ces fichiers dans un dossier. En effet, dans la config de Nginx, on peut utiliser des règles pour ces fichiers sans passer par des expressions régulières type '*\.txt$" ce qui est beaucoup plus rapide.
Pour les prochaines versions, ce serait bien de proposer à l'installation la possibilité de renommer les dossiers core/admin, core/lib et data.
Je t'ai envoyé un nouveau pull request sur la branche plx_root pour toutes ces modifs.
A++
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Pluxml regarde s'il existe une fonction onActivate ou OnDeactivate pour le plugin. AMHA, il manque une fonction OnDelete. En effet, certains plugins ont besoin de créer un dossier ou un fichier, qui ne sont pas forcément dans le dossier du plugin (Pb droit en écriture), selon la configuration demandée par l'utilisateur. Quand on supprime le plugin, ces fichiers/dossiers restent.
Les plugins peuvent être installés à la main sans passer par Pluxml, avec des droits en écriture pour l'administrateur du serveur différents des droits accordés au serveur web (typiquement www-data sur Debian et Ubuntu)
Quand on veut supprimer un plugin, Pluxml tente d'abord de supprimer le dossier du plugin. Si ça plante, on arrrête le processus et les fichiers de config et feuilles de style restent en l'état dans le dossier data/configuration.
Dans la fonction plxPlugins::saveConfig(..), il me semble logique de faire dans l'ordre : suppression des feuilles de style, suppression du paramétrage du plugin, mise à jour du fichier data/configuration/plugins.xml et enfin suppression du dossier du plugin dans le dossier plugins.
Hélas, actuellement on procède exactement dans l'ordre inverse.
Quand l'administrateur du serveur veut faire une mise à jour propre, il se retrouve avec les anciennes feuilles de style et l'ancienne config du plugin.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Le chargement d'image à partir du plugin plxeditor 1.4.1 ne fonctionne pas.
La validation est faite mais l'image n'apparait pas et n'est pas envoyée sur le serveur.
Le captcha du formulaire de contact du plugin MyContact ne fonctionne pas mais fonctionne bien dans les commentaires.
Sur une installation neuve :
Le formulaire d'envoi d'image du plugin plxeditor ne fonctionne pas non plus.
c'est noté https://github.com/pluxml/PluXml/issues/163
merci
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
5.4 ou 5.5 ?
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
On a déménagé les scripts javascript dans la nouvelle version de Pluxml mais l'intendance ne suit pas, en bref.
Il faut faire une mise à jour dans le plugin pour le fichier medias.php.
Evitons de réinventer la roue et utilisons le gestionnaire de médias core/medias.php de Pluxml pour suivre ses évolutions
Cela marche très bien dans d'autres plugins
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Il faut que je mette à jour plxEditor pour la V5.5 pour prendre la nouvelle gestion du gestionnaire de médias en mode fenêtré. C'est dans les tuyaux
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)