Lorsqu'on utilise la balise #URL_ARTICLE dans une boucle qui porte le
critère {recherche}, Spip ajoute automatiquement "?var_recherche=xxxx" à la
valeur de la balise.
Mais si on essaie de prendre la valeur de la balise quand on se trouve à
l'intérieur d'une autre boucle ARTICLES, en utilisant #NomDeBoucle:#URL_ARTICLE, le
"?var_recherche=xxxx" est perdu. Serait-il possible de le conserver?
Sinon, serait-il possible de pouvoir utiliser les valeurs des variables
d'URL, qui sont disponibles pour les critères dans le forme
"%nom_de_variable", aussi comme des balises dans les squelettes?
Lorsqu'on utilise la balise #URL_ARTICLE dans une boucle qui porte le
critère {recherche}, Spip ajoute automatiquement "?var_recherche=xxxx" à la
valeur de la balise.
Mais si on essaie de prendre la valeur de la balise quand on se trouve à
l'intérieur d'une autre boucle ARTICLES, en utilisant #NomDeBoucle:#URL_ARTICLE, le
"?var_recherche=xxxx" est perdu. Serait-il possible de le conserver?
C'est plus qu'une possibilité, c'est un devoir, car c'était un bug:
si tu avais mis "recherche" comme critere dans la boucle interne tu aurais eu
ce que tu aurais voulu, sauf que ça aurait été anormal !
Réparé sur le CVS.
Sinon, serait-il possible de pouvoir utiliser les valeurs des variables
d'URL, qui sont disponibles pour les critères dans le forme
"%nom_de_variable", aussi comme des balises dans les squelettes?
Ca c'est plus ennuyeux: tout les squelettes qui utilisent le signe "%"
risquent de ne plus tourner comme avant.
Si ta variable est un champ SQL C d'une table T,
tu peux toujours t'en sortir par
<BOUCLE1(T){C=%variable}>#C</BOUCLE1>
C'est plus qu'une possibilité, c'est un devoir, car c'était un bug:
Je ne voudrais pas faire peser les "devoirs" trop fort, car quand je
travaille sur un squelette parfois je pense que les bugs me trouvent tout
seuls!
Réparé sur le CVS.
Merci beaucoup. Je vais l'essayer dès que possible.
Sinon, serait-il possible de pouvoir utiliser les valeurs des variables
d'URL, qui sont disponibles pour les critères dans le forme
"%nom_de_variable", aussi comme des balises dans les squelettes?
Si ta variable est un champ SQL C d'une table T,
tu peux toujours t'en sortir par
<BOUCLE1(T){C=%variable}>#C</BOUCLE1>
Non, c'était juste pour contourner le problème ci-dessus: je voulais
reprendre "var_recherche" depuis l'URL. Mais comme tu as réparé le bug, je
n'en aurai pas besoin.
En effet, il y avait en fait 2 bugs là-dessus.
C'est réparé mais du coup je deviens sceptique sur la possibilité
de définir des nouveaux critères simplement en ajoutant des fonctions au compilo:
ca fait la 2e fois (le 1er c'etait les doublons de documents) qu'un critère influe
sur l'intégralité de la compilation et nécessite du coup une modif de son initialisation.
J'ai toujours le problème :
Warning: in_array(): Wrong datatype for second argument in
/raid/taize_devel/www/inc-compilo.php3 on line 540
qui a le comportement suivant :
il se montre seulement la première fois que la page est chargée, ou lorsque
je clique sur "recalculer cette page". Dès que la page est entrée en cache,
plus d'erreur.
ok, vu: dans le cas d'une boucle récursive le champ en question n'est pas un tableau,
il a raison de raler. Pour le cache, c'est normal: il n'y a (presque) plus de PHP à exécuter.
Réparé.
Emmanuel