Je détecte encore pas de mal de souci sur les fichiers de langue de PluXml.
Voici un script PHP qui montre les problèmes :
la même clé de traduction employée dans plusieurs fichiers (E.G. : L_ARTICLE, L_CATEGORY, L_NO_ARTICLE employés dans core.php et admin.php )
Plusieurs clés pour une même traduction (E.G. : L_PLUGINS_ACTION, L_COMMENTS_LIST_ACTION, L_CONFIG_USERS_ACTION, L_STATICS_ACTION, L_ARTICLE_LIST_ACTION pour "Action" )
Bonjour, j'avais l'habitude de travailler avec gitflow, mais ce n'est effectivement pas très adapté à l'usage de github, qui proposent d'ailleurs un workflow ou les PR se font sur la branche master. Pour quelqu'un qui arrive et qui souhaite contribuer c'est plus simple de partir de master, c'est vrai. Gardons ce fonctionnement, vous pouvez continuer de faire vos PR sur master, je vais merger puis supprimer les branches superflues et mettre à jour le readme ;-)
Je suis perplexe d'utiliser un tableau "$LANG" dans chaque fichier de langue fr.php, en.php, ... si c'est pour créer des constantes avec la function loadLang() dans core/li/config.php. Autant déclarer les constantes dans les fichiers de langue.
Actuellement on parse le tableau à chaque execution pour générer une page HTML.
AMHA, si les constantes étaient dans les fichiers de langue elles sont compilées une fois pour toute et le bytecode généré est stocké dans le cache u moteur PHP.
Avec les 613 clés de traduction, PluXml devrait être plus réactif.
Je vais essayer de faire un script en PHP ou en Python pour transformer ces fichiers de langue.
Je vais voir si j'ai intérêt à supprimer avant les clés de traductions en double en utilisant l'anglais pour le nom des clés
Pour afficher les différentes traductions lorsque qu'une même clé est utilisée dans plusieurs fichiers, on peut se placer dans le dossier "core" et exécuter la commande en-une-ligne suivante :
for lang in `ls`; do if [ -d $lang ]; then grep -E '\bL_(CATEGORY|NO_ARTICLE|SAVE_SUCCESFUL|WRONG_PHP_VERSION|SELECT_LANG|INPUT_CHANGE|LOGIN)\b' $lang/*.php; echo "-----"; fi done
Le résultat pique un peu les yeux. Pour certaines langues, la traduction diffère d'un fichier à l'autre.
Il y a des traductions un peu bizarre Par exemple en espagnol, pour L_NO_ARTICLE, j'aurais plutôt traduit par "sin articulo"
Pour la clé L_WRONG_PHP_VERSION il faut utiliser "printf" avec "%s" et mettre une constante pour la version minimale requise pour PHP. Sinon on va être obligé PHP 5.5 😪
Comme core.php est chargé en dernier dans core/admin/prepend.php, les clés en double dans admin.php sont inutilisées. On peut les supprimer avec "sed". Par exemple pour "L_CATEGORY" :
Pour fusionner les clés L_COMMENTS_LIST_ACTION, L_CONFIG_USERS_ACTION, L_STATICS_ACTION, L_ARTICLE_LIST_ACTION, L_PLUGINS_ACTION en L_ACTION, on peut faire le faire comme ceci en se plaçant dans le dossier core :
Mon PluXml 5.8.3 en dev modifié s'installe, se met a jour et tourne bien chez toile-libre.org (PHP 5.5.38 + short_open_tag activé), si tu veux le tester, télécharge le directement depuis mon espace github : PluXml 5.8.3.legacy
Bonjour, après quelques mois (2 années) sans toucher php et pluxml, Je me suis remonté un petit serveur pour faire joujou à mon temps libre (enfin quand j'en ai, ce qui est rarement le cas) et donc immanquablement remettre mon PluX adoré histoire de rester léger.
Après avoir bataillé un peu pendant deux heures avec mon cerveau lent et ma mémoire défaillante pour installer ngnix/php/certificat/etc... configurer les droits, le TLS etc...
L'installation de PluXml 5.8.2 s'est bien déroulé en quelques minutes, tip-top parfait, plus qu'à m'attaquer au thème et aux plugins.
Quel joie de retrouver un PluX léger, une communauté toujours active et avec une nouvelle version.
(sinon je ne sais pas ce qu'est « short_open_tag activé »)
Tu l'as fait pour toi aussi ou juste pour moi ?
Merci dans tous les cas ! 🤗
Si c'est juste pour moi, peut être veux tu indiquer ici tes modifs pour que je puisse faire les changements moi-même sur la prochaine version sans te déranger ?
Par contre je viens d'activer la compression puis d'activer la réécriture d'url qui était off et boum badaboum. Je crois que c'est la réécriture d'url qui est la cause, ou bien c'est une coincidence
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, you@example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
La réécriture d'url est impossible chez toile libre (plusieurs essais infructueux) mais la compression Gzip fonctionne bien 😉
Je l'ai fait pour plusieurs sites qui tournent chez eux (dont un avec les greffons adhésion+Sel, ...)
Pour short_open_tag actif: c'est lorsque l'on peut écrire <? pour ouvrir du code php (au lieu de <?php) ce qui posais quelques soucis avec la nouvelle page de l'installeur faite par Bazooka07 que j'ai adopté.
Au cas ou, en général, ce sont les constantes en tableaux et celles déclarés avec le mot clé const concaténés qui cause des problèmes en PHP 5.5
Auparavant en allant sur github , on avait en cliquant sur master la derniere version en cours et on avait la version develop où il y avait régulierement des correctifs apportés.
C'est cette version develop que je téléchargeais régulierement pour travailler en local.
Hors depuis quelques jours il y a des modifications apportées à cette version master sans qu'elles aient été apportées à la version develop..
J'ai tout réinstallé, activé la compression et tout roule 🤗
Je n'ai pas retenté le diable avec la réécriture d'url pour vérifier si c'est bien ce qui a tout planté car j'aimerais faire une pause dans la réinstallation de mon blogue 🤪 mais par déduction on peut avec une forte probabilité conclure cela
Merci beaucoup pour ton travail d'adaptation et à l'équipe pour ces mises à jour 🤠
Effectivement, on est revenu sur le fonctionnement d'avant car c'est plus simple pour les contributions. C'est aussi ce que recommande Github (merger les pull request sur master). J'ai donc supprimé les branches bugfix et develop. La version en cours de dev est sur la branche master et la version stable (releases) correspond à un tag Git qui porte le numéro de version de PluXml ("v5.8.2").
En cas de doute, voir la page README.md qui est à jour et précise tout ça.
Je crois qu'il y a un bogue lié à l'activation des commentaires sous chaque article.
je me suis rendu compte que sous certains de mes billets les commentaires étaient désactivés (ce n'est pas propre à ta version : j'ai eu ce bogue précédemment où j'ai fait une désactivation générale depuis Paramètres>Configuration de base, et lorsque j'ai fait une réactivation générale cela ne s'est pas propagé à tous les articles).
En revanche ce qui semble nouveau comme bogue c'est que, sous les articles, la case "Autoriser les commentaires" est toujours sur "Oui", même quand ils sont fermés. Concernant un article dont les commentaires étaient fermés en fait bien que la case indique "Oui", j'ai fait le test en le basculant à non/oui. Les commentaires se rouvrent et se ferment bien, mais la case affiche toujours "Oui" une fois le réglage sauvegardé (au lieu de refléter l'état actuel du réglage).
Bonjour,
Je continue mes remontées :
J'ai tenté de modifier un commentaire, qui était une réponse sous un autre commentaire, et la page d'édition est vide : elle ne montre pas le commentaire à modifier. D'ailleurs, peut-être est-ce lié, l'ordre chronologique n'est pas respecté dans la fenêtre d'administration, où la réponse à la réponse apparaît antérieure à la réponse dans l'ordre de présentation. J'ai :
Réponses
Bonjour,
Avant ton arrivée, on avait l'habitude d'envoyer des push-requests (PR ) sur la branche master de Github.
Fault-il encore se baser sur cette branche ou basculer sur bugfix ?
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour,
Je détecte encore pas de mal de souci sur les fichiers de langue de PluXml.
Voici un script PHP qui montre les problèmes :
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Et voici le résultat :
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
On doit pouvoir résoudre le problème avec un utilitaire comme sed. Mais il faut une bonne maitrise de l'outil.
Je n'ai pas vérifié si toutes ces clés de traduction étaient utiles. A vérifier.
Attention également aux pluriels :
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour, j'avais l'habitude de travailler avec gitflow, mais ce n'est effectivement pas très adapté à l'usage de github, qui proposent d'ailleurs un workflow ou les PR se font sur la branche master. Pour quelqu'un qui arrive et qui souhaite contribuer c'est plus simple de partir de master, c'est vrai. Gardons ce fonctionnement, vous pouvez continuer de faire vos PR sur master, je vais merger puis supprimer les branches superflues et mettre à jour le readme ;-)
Merci pour le script sur les langues, j'ai créé une issue sur github https://github.com/pluxml/PluXml/issues/388
Cela m'a échappé jusqu'à présent :
Je suis perplexe d'utiliser un tableau "$LANG" dans chaque fichier de langue fr.php, en.php, ... si c'est pour créer des constantes avec la function loadLang() dans core/li/config.php. Autant déclarer les constantes dans les fichiers de langue.
Actuellement on parse le tableau à chaque execution pour générer une page HTML.
AMHA, si les constantes étaient dans les fichiers de langue elles sont compilées une fois pour toute et le bytecode généré est stocké dans le cache u moteur PHP.
Avec les 613 clés de traduction, PluXml devrait être plus réactif.
Je vais essayer de faire un script en PHP ou en Python pour transformer ces fichiers de langue.
Je vais voir si j'ai intérêt à supprimer avant les clés de traductions en double en utilisant l'anglais pour le nom des clés
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Pour afficher les différentes traductions lorsque qu'une même clé est utilisée dans plusieurs fichiers, on peut se placer dans le dossier "core" et exécuter la commande en-une-ligne suivante :
Le résultat pique un peu les yeux. Pour certaines langues, la traduction diffère d'un fichier à l'autre.
Il y a des traductions un peu bizarre Par exemple en espagnol, pour L_NO_ARTICLE, j'aurais plutôt traduit par "sin articulo"
Pour la clé L_WRONG_PHP_VERSION il faut utiliser "printf" avec "%s" et mettre une constante pour la version minimale requise pour PHP. Sinon on va être obligé PHP 5.5 😪
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Comme core.php est chargé en dernier dans core/admin/prepend.php, les clés en double dans admin.php sont inutilisées. On peut les supprimer avec "sed". Par exemple pour "L_CATEGORY" :
Et "tutti canti"
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Pour fusionner les clés L_COMMENTS_LIST_ACTION, L_CONFIG_USERS_ACTION, L_STATICS_ACTION, L_ARTICLE_LIST_ACTION, L_PLUGINS_ACTION en L_ACTION, on peut faire le faire comme ceci en se plaçant dans le dossier core :
"git commit" donne :
grep ne sert qu'à vérifier que l'avancement du travail.
Il suffit ensuite de se connecter à PluXml et de faire le tour du menu pour vérifier les fichiers listés par :
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
@antistress
Mon PluXml 5.8.3 en dev modifié s'installe, se met a jour et tourne bien chez toile-libre.org (PHP 5.5.38 + short_open_tag activé), si tu veux le tester, télécharge le directement depuis mon espace github : PluXml 5.8.3.legacy
@+
Notre temps est la seule monnaie vraie ;)
Site, Dépôt, framagit, MyShop, Factux
#mozinor président
Bonjour, après quelques mois (2 années) sans toucher php et pluxml, Je me suis remonté un petit serveur pour faire joujou à mon temps libre (enfin quand j'en ai, ce qui est rarement le cas) et donc immanquablement remettre mon PluX adoré histoire de rester léger.
Après avoir bataillé un peu pendant deux heures avec mon cerveau lent et ma mémoire défaillante pour installer ngnix/php/certificat/etc... configurer les droits, le TLS etc...
L'installation de PluXml 5.8.2 s'est bien déroulé en quelques minutes, tip-top parfait, plus qu'à m'attaquer au thème et aux plugins.
Quel joie de retrouver un PluX léger, une communauté toujours active et avec une nouvelle version.
Donc merci pour la MAJ :)
Bonne continuation.
Buster/NGINX/PHP7/PluXml5.8
@Sudwebdesign
Hello, me revoilà pardon pour le délai :)
Testé et approuvé visiblement !
PluXml version 5.8.3 (encodage UTF-8)
(sinon je ne sais pas ce qu'est « short_open_tag activé »)
Tu l'as fait pour toi aussi ou juste pour moi ?
Merci dans tous les cas ! 🤗
Si c'est juste pour moi, peut être veux tu indiquer ici tes modifs pour que je puisse faire les changements moi-même sur la prochaine version sans te déranger ?
Oups.
Par contre je viens d'activer la compression puis d'activer la réécriture d'url qui était off et boum badaboum. Je crois que c'est la réécriture d'url qui est la cause, ou bien c'est une coincidence
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, you@example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
@antistress
La réécriture d'url est impossible chez toile libre (plusieurs essais infructueux) mais la compression Gzip fonctionne bien 😉
Je l'ai fait pour plusieurs sites qui tournent chez eux (dont un avec les greffons adhésion+Sel, ...)
Pour short_open_tag actif: c'est lorsque l'on peut écrire <? pour ouvrir du code php (au lieu de <?php) ce qui posais quelques soucis avec la nouvelle page de l'installeur faite par Bazooka07 que j'ai adopté.
Au cas ou, en général, ce sont les constantes en tableaux et celles déclarés avec le mot clé const concaténés qui cause des problèmes en PHP 5.5
Notre temps est la seule monnaie vraie ;)
Site, Dépôt, framagit, MyShop, Factux
#mozinor président
Bonjour,
Auparavant en allant sur github , on avait en cliquant sur master la derniere version en cours et on avait la version develop où il y avait régulierement des correctifs apportés.
C'est cette version develop que je téléchargeais régulierement pour travailler en local.
Hors depuis quelques jours il y a des modifications apportées à cette version master sans qu'elles aient été apportées à la version develop..
@Sudwebdesign
Merci 🙂
J'ai tout réinstallé, activé la compression et tout roule 🤗
Je n'ai pas retenté le diable avec la réécriture d'url pour vérifier si c'est bien ce qui a tout planté car j'aimerais faire une pause dans la réinstallation de mon blogue 🤪 mais par déduction on peut avec une forte probabilité conclure cela
Merci beaucoup pour ton travail d'adaptation et à l'équipe pour ces mises à jour 🤠
@cpalo
Il a eu aussi une branch bugfix.
Le souci c'est quand on pousse une modification pour PluXml sur github.com, on a besoin de savoir à partir de quelle branch on part.
Et entre master, develop, bugfix, etc, on ne savait plus où s'accrocher.
Donc, j'ai fini par poser dans une discussion la question à @p3ter et on a convenu qu'on va continuer à proposer les améliorations sur master.
Quand tous les problèmes seront résolus, une release sera publiée sur Github et Pluxml.
En fait, c'est le retour comme avant.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Effectivement, on est revenu sur le fonctionnement d'avant car c'est plus simple pour les contributions. C'est aussi ce que recommande Github (merger les pull request sur master). J'ai donc supprimé les branches bugfix et develop. La version en cours de dev est sur la branche master et la version stable (releases) correspond à un tag Git qui porte le numéro de version de PluXml ("v5.8.2").
En cas de doute, voir la page README.md qui est à jour et précise tout ça.
Une version 5.8.3 est en préparation. Il reste quelques petits détails à régler et on pourra lancer la phase de test ;-)
Yes merci pour le suivi !
Pour avoir monté récemment un site sur Wordpress, je pleurais devant l'usine à gaz sans fin que c'était. 💀
@Sudwebdesign
Je pense par contre que les flux RSS sont cassés (articles, commentaires) depuis la mise à jour...
@antistress merci du retour
Oups 2 oublis corrigés (feed et sitemap) non testé PLM mais cela devrai rouler😉
PluXml 5.8.3.legacy
@+
Notre temps est la seule monnaie vraie ;)
Site, Dépôt, framagit, MyShop, Factux
#mozinor président
@Sudwebdesign
flux RSS réparés, merci :)
Par contre http://libre-ouvert.toile-libre.org/sitemap.xml ne donne rien : c'est quoi l'adresse du plan du site sur pluxml ?
@antistress http://libre-ouvert.toile-libre.org/sitemap.php 😉
il est possible d'utiliser le https https://libre-ouvert.toile-libre.org/sitemap.php
Notre temps est la seule monnaie vraie ;)
Site, Dépôt, framagit, MyShop, Factux
#mozinor président
@Sudwebdesign
Merci !
Je crois qu'il y a un bogue lié à l'activation des commentaires sous chaque article.
je me suis rendu compte que sous certains de mes billets les commentaires étaient désactivés (ce n'est pas propre à ta version : j'ai eu ce bogue précédemment où j'ai fait une désactivation générale depuis Paramètres>Configuration de base, et lorsque j'ai fait une réactivation générale cela ne s'est pas propagé à tous les articles).
En revanche ce qui semble nouveau comme bogue c'est que, sous les articles, la case "Autoriser les commentaires" est toujours sur "Oui", même quand ils sont fermés. Concernant un article dont les commentaires étaient fermés en fait bien que la case indique "Oui", j'ai fait le test en le basculant à non/oui. Les commentaires se rouvrent et se ferment bien, mais la case affiche toujours "Oui" une fois le réglage sauvegardé (au lieu de refléter l'état actuel du réglage).
Il y a effectivement un bug, j'ai créé un ticket sur Github : https://github.com/pluxml/PluXml/issues/402
Et un bogue avec plxToolbar - Version 1.5.1 : je le rapporte où ?
Quand on clique sur le bouton liste numérotée il génère ceci:
<ol>
</li></li>
</ol>
Teins je découvre cette nouveauté : image d'accroche, dans la fenêtre de rédaction
Bizarrement si je prends une image de mon dossier média, par exemple en 400x300, il va m'afficher la vignette cliquable et pas l'image 400x300
Bien que dans Paramètres, Options d'affichage, j'ai :
Taille des images (largeur x hauteur) : 800 x 600
Taille des miniatures (largeur x hauteur) : 200 x 100
Créer miniatures : oui
Ha oui, et elle n'est pas centrée, et je ne peux ni mettre un lien vers la source de l'image, ni une légende.
Pour un exemple en 400x300 avec lien et centrée, fait à la main : http://libre-ouvert.toile-libre.org/index.php?article205/au-revoir-debian-bonjour-debian-avec-flatpak-mise-jour
Ici en 300 de large, centrée avec légende : http://libre-ouvert.toile-libre.org/index.php?article27/l-extension-du-jour-update-scanner-pour-firefox
Bonjour,
Je continue mes remontées :
J'ai tenté de modifier un commentaire, qui était une réponse sous un autre commentaire, et la page d'édition est vide : elle ne montre pas le commentaire à modifier. D'ailleurs, peut-être est-ce lié, l'ordre chronologique n'est pas respecté dans la fenêtre d'administration, où la réponse à la réponse apparaît antérieure à la réponse dans l'ordre de présentation. J'ai :
au lieu de :