Pour info, j’ai modifié
et
pour mettre en avant la nouvelle syntaxe des fichiers de langues (avec un return direct), nettement plus facile et qui sera la seule supportée en SPIP 6.0. Ca laisse un peu de temps, mais autant donner des bonnes habitudes.
Merci, c’est très utile.
Tu vois, je ne m’étais même pas rendu compte de la transformation de la variable globale en fonction à appeller, alors que je m’occupe d’abord de la traduction.
Apparamment je ne « fais » pas assez de SPIP ce dernier temps.
Est-ce qu’il y a d’autres modification récentes peut-être encore plus subtiles dans le système de gestion de langues, par exemple en ce qui concerne le fonctionnement de trad.spip.net ?
:-)k++
pas à ma connaissance, et trad.spip.net gère cela de manière transparente. Et comme l’ancienne syntaxe est encore supportée et que de nombreux plugins l’utilisent encore, c’est assez normale de pas avoir vu, sauf à lire attentivement les billet de release.
Hello
J’ai 2 questions :
Pour un plugin utilisable de spip 4.0 à spip 4.3, je suppose qu’il faut garder l’ancienne syntaxe ?
Dans les fichiers de langue, j’ai aussi au début un
if (!defined('_ECRIRE_INC_VERSION')) {
return;
}
Doit-on le garder avec la nouvelle syntaxe ou pas ?
je dirais OUI, car au lus récents sur ce sujet, c’est nécessaire dès lors qu’il y a exécution d’un code et non seulement des déclarations. Tant l’ancienne que la nouvelle syntaxe le nécessitent.
Sauf qu’on peut considérer que le contenu des fichiers de langue, c’est déclaratif. C’est pas tant du code que de la donnée …
L’exécution de code, c’est à considérer au « runtime », c’est plutôt des echo, die(), exit(), headers(), … (c’est pas exhaustif), directement dans le fichier, pas dans le corps d’une fonction ou d’une méthode de classe
Voir PSR-1 Side Effects
Certes, mais dire ça c’est une forme de jeu sur les mots.
Avec if (!defined('_ECRIRE_INC_VERSION')) { return; }, il s’agit de sécurité, pas de nommage (« déclaratif » ou pas) ni de respect des standards de l’esthétique du codage.
Alors indépendamment de comment on qualifie « return $val » ou « $var=$val », il serait utile de préciser quand il faut énoncer ou pas le mantra if (!defined('_ECRIRE_INC_VERSION')) { return; } ?
Je te dirais bien jamais… vu le peu d’utilité de la chose… c’est très historique… mais pour te répondre,
un fichier qui ne fait QUE des déclarations (de classes, de fonctions) n’a pas besoin de ça.
un fichier qui ne fait QUE retourner un tableau / un objet (comme ici langues), sans utiliser de variables extérieures ($_GET par exemple) n’en a pas besoin…
un fichier qui exécute directement du code (comme souvent des fichiers xx_options.php) pourrait en avoir besoin.
non, pas du tout.
Oui, quand on était limité par les include et require de PHP3, je crois. Depuis, c’est juste devenu un cargo-culte, un dogme…
Y a pas d’obligation ! vous pouvez les laisser si vous voulez. Personne n’a dit, me semble-t-il, que c’est une règle absolue à respecter militairement ! C’est aux devs de décider et de savoir ce qu’il se passe dans leur fichier 
Oui, voilà, c’est mieux dit.
Cette syntaxe est valide à partir de SPIP 4.1. Donc si tu veux être compatible 4.0 (note que cette branche n’est plus maintenue), il faut conserver l’ancienne écriture.
Merci.
Je pense assurément que quitte à modifier des articles de SPIP ou Programmer, il faut adapter le format d’écriture à comme le font un peu les articles de doc de PHP : mettre juste la syntaxe valide actuelle dans le contenu de l’article… et faire une section Historique à la fin de l’article uniquement avec les changements qu’il y a eu et les versions.
Sinon on se retrouve avec plein de « depuis 1.9 » ou « avant 2.1 » un peu partout, et c’est pas le plus lisible je trouve
oui, oki, moi ca me va. J’avoue là pas le courage de corriger, mais si d’autres de la team @documentation ont le courage de le faire ^
Je vais essayer de mettre à jour ce soir.
Une question : logiquement la partie « historique » on la met complètement à la fin, après la partie « voir aussi » ?
Fait
merci !
Je note que
Déprécier en SPIP 5.0, supprimé en 6.0 … en fait je pense que ça m’ennuie que ça dure autant…
@maintenance : est-ce qu’on pourrait les déprécier ces globales dès SPIP 4.4 et les supprimer en 5.0 ?
Je rappelle que cette nouvelle syntaxe est valide dès SPIP 4.1 (4.1.0 est sortie le 25 mars 2022).
Est-ce trop court ou pas ?
C’est jouable, selon moi.
Je comprend et je suis plutot favorable aussi. Pour info j’ai ouvert une PR dans langonet à ce sujet Lire et generer les fichiers selon la nouvelle syntaxe (!2) · Requêtes de fusion · spip-contrib-extensions / langonet · GitLab
et j’imagine qu’on peut facilement écrire un script bash, qui grep tout ce qui est compatible 4.1 ou plus et modifie les fichiers, vu que c’est juste remplacer un $GLOBALS[xxx] = par un return.
On scinderait pas par contre le sujet ? pour mettre cela dans la catégorie maintenance
J’en ai un. Tu veux une liste ?