a introduit une modification fonctionnelle pour permettre de déclarer les fonctions balise_MABALISE_dyn() et balise_MABALISE_stat() d'une balise autre part que dans le fichier balise/mabalise.php homonyme.
Pour cela il utilise une ReflectionFunction pour trouver le nom du fichier qui contient la fonction balise_MABALISE() au lieu du résultat d'un include_spip comme en 3.0
Cela produit un bug concret : si un des dossiers sur le chemin du fichier est un lien symbolique (par exemple mon dossier plugins/), le chemin retourné par getFileName() est un chemin qui n'est pas celui de SPIP, et on le tronque à la longueur de strlen(_ROOT_CWD) ce qui n'a pas de sens. Du coup le nom de chemin est faux, la compilation produit un include_once qui ne fait rien et on a une fatal erreur.
Sur le fond, je pense que le code n'est pas exact, car on utilise le nom de fichier qui contient la fonction balise_MABALISE() sans verifier qu'il contient aussi balise_MABALISE_dyn qu'on va utiliser. On n'a donc pas fait exactement ce qui était annoncé (il faut que la fonction balise_MABALISE_dyn soit dans le meme fichier que balise_MABALISE).
Je ne vois pas comment réparer ce code pour repasser d'un chemin absolu fourni par la ReflectionFunction vers un chemin relatif qui sera utilisé par le compilateur, précédé de _DIR_RACINE.
Ou alors il faut modifier synthetiser_balise_dynamique() pour qu'elle accepte un chemin relatif (en le prefixant dans le code de _DIR_RACINE) et un chemin absolu.
Alternativement on peut revenir à l'état précédent.
Un avis ?
a introduit une modification fonctionnelle pour permettre de déclarer les fonctions balise_MABALISE_dyn() et balise_MABALISE_stat() d'une balise autre part que dans le fichier balise/mabalise.php homonyme.
Pour cela il utilise une ReflectionFunction pour trouver le nom du fichier qui contient la fonction balise_MABALISE() au lieu du résultat d'un include_spip comme en 3.0
Cela produit un bug concret : si un des dossiers sur le chemin du fichier est un lien symbolique (par exemple mon dossier plugins/), le chemin retourné par getFileName() est un chemin qui n'est pas celui de SPIP, et on le tronque à la longueur de strlen(_ROOT_CWD) ce qui n'a pas de sens. Du coup le nom de chemin est faux, la compilation produit un include_once qui ne fait rien et on a une fatal erreur.
Oui… effectivement ça ne convient pas.
Sur le fond, je pense que le code n'est pas exact, car on utilise le nom de fichier qui contient la fonction balise_MABALISE() sans verifier qu'il contient aussi balise_MABALISE_dyn qu'on va utiliser. On n'a donc pas fait exactement ce qui était annoncé (il faut que la fonction balise_MABALISE_dyn soit dans le meme fichier que balise_MABALISE).
Je ne vois pas comment réparer ce code pour repasser d'un chemin absolu fourni par la ReflectionFunction vers un chemin relatif qui sera utilisé par le compilateur, précédé de _DIR_RACINE.
Ou alors il faut modifier synthetiser_balise_dynamique() pour qu'elle accepte un chemin relatif (en le prefixant dans le code de _DIR_RACINE) et un chemin absolu.
Alternativement on peut revenir à l'état précédent.
Un avis ?
Le plus simple est de revert oui.
Maat soulevait
A) l'incohérence de pouvoir déclarer dans mes fonctions sa balise (même dynamique) mais qu'on ne pouvait pas mettre à côté les fonctions _dyn ou _stat .
B) une fausse tentative de charger une balise générique même si ça n'a pas lieu d'être (lorsqu'il n'y a pas de _ dans le nom de balise).
Si c'est vraiment utile, on pourra toujours revenir dessus… plus tard ?