A noter qu'on ne peut actuellement faire co-exister Propre et Arbo car elles déclarent le même pipeline ({{{creer_chaine_url}}}), il faudrait revoir ce code.
A noter qu'on ne peut actuellement faire co-exister Propre et Arbo car elles déclarent le même pipeline ({{{creer_chaine_url}}}), il faudrait revoir ce code.
normalement ce n'est pas gênant
je me suis mal exprimé: il y a 2 fonctions qui ont le meme nom dans ces deux fichiers, et ce nom est celui destiné à un pipe-line. Il faut donc revoir ce code pour qu'on puisse inclure ces deux fichiers en même temps.
Corrigé par 12434. Ce qui est marrant c'est que chez moi j'avais aussi "ecrire/" mais que ça visualisait quand meme. Un effet secondaire de profondeur_url ?
je me suis mal exprimé: il y a 2 fonctions qui ont le meme nom dans ces deux
fichiers, et ce nom est celui destiné à un pipe-line. Il faut donc revoir ce
code pour qu'on puisse inclure ces deux fichiers en même temps.
ah ok, il doit suffire de prefixer
Corrigé par 12434. Ce qui est marrant c'est que chez moi j'avais aussi
"ecrire/" mais que ça visualisait quand meme. Un effet secondaire de
profondeur_url ?
c'est le travail pour les urls arbos, le mix .htaccess /
page_href_base() en effet
Préfixer les fonctions ou le nom du pipeline ?
J'ai pas regardé en détail, mais ces deux fonctions se ressemblent beaucoup il y a peut-être moyen d'en faire une seule plus générale ce qui serait plus utile.
Autre chose autour de ça. Puisque depuis un bon moment déjà public_parametrer_dist déroule explicitement du code destiné à la compatibilité, je serais partisan de se débarasser de l'interface actuelle qui utilise une variable globale ($contexte) et un passage par référence ($fond) pour établir le contexte de compilation. Une spécification sécurisée et souple est une spécification exclusivement fonctionnelle: une fonction reçoit des valeurs et retourne une valeur. Manipuler des références est potentiellement dangereux.
J'ai pas regardé en détail, mais ces deux fonctions se ressemblent beaucoup
il y a peut-être moyen d'en faire une seule plus générale ce qui serait plus
utile.
sans doute
Autre chose autour de ça. Puisque depuis un bon moment déjà
public_parametrer_dist déroule explicitement du code destiné à la
compatibilité, je serais partisan de se débarasser de l'interface actuelle
qui utilise une variable globale ($contexte) et un passage par référence
($fond) pour établir le contexte de compilation. Une spécification sécurisée
et souple est une spécification exclusivement fonctionnelle: une fonction
reçoit des valeurs et retourne une valeur. Manipuler des références est
potentiellement dangereux.
Il faut pouvoir fixer le $fond à partir de l'url courante, je
l'utilise tout le temps.
Un exemple est pour dire que si l'url est rubrique1.rss on veut le
fond rss.html, avec le contexte id_rubrique=1
Je te laisse faire alors parce que visiblement ces fonctions ne sont pas appelées en standard, ça doit concerner un plugin mais je ne sais pas lequel.
Il faut pouvoir fixer le $fond à partir de l'url courante, je
l'utilise tout le temps.
Bien sûr, ce n'est pas ça que je remets en cause.
L'idée est que puisqu'on teste à présent l'existence de la fonction "recuperer_parametre_url", qui existe en SPIP depuis le début mais a disparu à présent, on peut donc dire que si cette fonction est définie on utilise l'ancienne interface affectant la globale "contexte" et modifiant son premier paramètre, et si elle ne l'est pas on utilise une nouvelle interface.