[spip-dev] <INCLURE> avec fond variable

Bonsoir,
Quelque chose qui marchait il y a 48 heures ne marche plus, j'ai
l'impression, avec la CVS actuelle.
Il s'agit de pouvoir passer un "fond" variable à ce nouveau fichier
page.php3 (légèrement modifié pour fonctionner avec <INCLURE>). De cette
façon:

<BOUCLE_addendum(MOTS){type=addendum}>
    <INCLURE(page.php3){fond=#TITRE}{...}>
</BOUCLE_addendum>

- - - -
où les lignes dans page.php3 sont :

$fond = $contexte_inclus['fond'];

if (ereg("\/", $fond)) die ("Ben voyons");
if (strpos("\.\.", $fond) > 0) die ("Faut pas se gener");

$delais = 3600;
include ("inc-public.php3");

- - - -
Alors,
<INCLURE(page.php3){fond=monsquelette}...
marche. Est-il possible que
<INCLURE(page.php3){fond=#TITRE}
remarchera ?

merci, Paolo

J'ai écrit:

Quelque chose qui marchait il y a 48 heures ne marche plus,

Pardon. Je dois me tromper - je n'arrive pas à le faire marcher maintenant
avec un Spip d'il y a deux jours.

N'empêche que :
    <INCLURE(page.php3){fond=#TITRE}>

....

$fond = $contexte_inclus['fond'];

sera utile s'il est possible.

Paolo

Quelque chose qui marchait il y a 48 heures ne marche plus, j'ai
l'impression, avec la CVS actuelle.
Il s'agit de pouvoir passer un "fond" variable à ce nouveau fichier
page.php3 (légèrement modifié pour fonctionner avec <INCLURE>). De cette
façon:

<BOUCLE_addendum(MOTS){type=addendum}>
    <INCLURE(page.php3){fond=#TITRE}{...}>
</BOUCLE_addendum>

Paolo, tu aimes toujours pousser le système dans ses derniers
retranchements, et tu y arrives très bien :slight_smile:

Pour ce que tu veux faire, la méthode que tu choisis n'est pas forcément
recommandée, puisqu'elle permet à n'importe quel rédacteur qui peut modifier
un mot-clé de provoquer des dégâts sur le site. Mais c'est aussi peut-être à
nous de renforcer la sécurité dans page.php3, plutôt que de laisser les gens
prendre des risques.

Cela dit, il me semble, en regardant un peu ce qui se passe, que tu as fait
remonter deux bugs dans l'analyse des boucles :

1) un bug dans calcul_inclure(), puisqu'on propage $idb alors que la
variable est initialisée sous le nom de $id_boucle. Mais ça n'est pas
nouveau.

2) un autre bug dans calculer_param_dynamique(), où id_boucle et id_mere
sont inversés. Là encore, ça n'est pas nouveau...

Du coup en fait le compilateur est perdu, et, dans le cas que tu décris,
cherche le #TITRE n'importe où sauf dans la boucle courante. Il va donc
chercher $Pile[0]['TITRE'], qui est vide, au lieu de $Pile[$SP]['titre'] (le
titre de l'objet courant).

Je corrige ces deux bugs -- en prime ça corrige aussi d'autres problèmes
plus difficiles à repérer, par exemple le fait que la langue (qui sert à la
typo) n'était pas correctement récupérée dans certains cas.

Maintenant ça devrait marcher, sur le plan compilo du moins.

-- Fil

Paolo, tu aimes toujours pousser le système dans ses derniers
retranchements, et tu y arrives très bien :slight_smile:

comme quoi il faut pas hesiter à demander la lune ... j'allais lui faire passer une "bidouille qui marche" (passage des variables dans le _GET et utilisation de #ENV) pensant que ce genre de choses n'etait pas (encore) possible.

Maintenant ça devrait marcher, sur le plan compilo du moins.

On va tester tout ca ...
Merci.

PS : Paolo, tu devrais mettre tes squelettes inclus dans un sous repertoire, voire leur affecter une convention de nommage (prefixe par exemple) et mettre ca en dur :

if (ereg("\/", $fond)) die ("Ben voyons");
if (strpos("\.\.", $fond) > 0) die ("Faut pas se gener");
$fond = "monchemin/prefixe".$contexte_inclus['fond'];

Ca limite les risque, mais il faut bien reflechir à ce qu'on met dans les mains des redacteurs ...

exemple) et mettre ca en dur :

if (ereg("\/", $fond)) die ("Ben voyons");
if (strpos("\.\.", $fond) > 0) die ("Faut pas se gener");
$fond = "monchemin/prefixe".$contexte_inclus['fond'];

Je viens de travailler là-dessus -- je propose que page.php3 n'accepte *que*
des squelettes installés dans le répertoire squelettes/ (ou un de ses
sous-répertoires).

Ca évitera toute embrouille tordue (à vérifier tout de même au niveau des
squelettes des balises dynamiques, mais a priori ils ne peuvent pas faire de
mal s'ils sont appelés en statique).

-- Fil

Fil wrote:

Paolo, tu aimes toujours pousser le système dans ses derniers
retranchements, et tu y arrives très bien :slight_smile:

Je m'excuse ! Faut pas hésiter à me dire si je demande trop...

n'importe quel rédacteur qui peut modifier
un mot-clé de provoquer des dégâts sur le site.

Je peux déjà limiter ce mot-clé aux admins. C'est vrai qu'il serait encore
mieux si je pouvais le limiter au admin principal.

Je corrige ces deux bugs -- en prime ça corrige aussi d'autres problèmes
plus difficiles à repérer,

Oui cela marche. Merci.
Mais avec ça un autre problème a surgi! Je vais essayer de comprendre plus
exactement ce qui se passe.

Paolo

Fil écrit:

Je corrige ces deux bugs -- en prime ça corrige aussi d'autres problèmes

Alors, le problème qui est apparu avec ce changement est que cette boucle ne
marche plus:

<BOUCLE_toplevelarticles(ARTICLES){id_rubrique IN
#ID_RUBRIQUE,#_chap:ID_RUBRIQUE}>

Alors que #ID_RUBRIQUE = 593 et #_chap:ID_RUBRIQUE = 43 (valeurs vérifiées
juste avant la boucle), la boucle ne rend pas les articles de ces boucles
mais seulement un article "invisible" publié à la racine du site dont
id_rubrique = 0.

Paolo

> Je corrige ces deux bugs -- en prime ça corrige aussi d'autres problèmes

Alors, le problème qui est apparu avec ce changement est que cette boucle ne
marche plus:

<BOUCLE_toplevelarticles(ARTICLES){id_rubrique IN
#ID_RUBRIQUE,#_chap:ID_RUBRIQUE}>

Alors que #ID_RUBRIQUE = 593 et #_chap:ID_RUBRIQUE = 43 (valeurs vérifiées
juste avant la boucle), la boucle ne rend pas les articles de ces boucles
mais seulement un article "invisible" publié à la racine du site dont
id_rubrique = 0.

Bizarre, chez moi la boucle que tu indiques fonctionne sans problème. Et la
version compilée (me dit le débugueur) semble correspondre à ce qu'on veut,
à savoir :

        {id_rubrique IN #ID_RUBRIQUE,#_chap:ID_RUBRIQUE}

est traduit par :
        array("articles.id_rubrique IN ('" . addslashes($Pile[$SP]['id_rubrique']) . "','" . addslashes($Pile[$SP-1]['id_rubrique']) . "')",

$Pile[$SP] signifie = les valeurs de cette boucle
$Pile[$SP-1] = les valeurs de la boucle précédente (i.e. _chap)

Squelette de tests :

<BOUCLE_chap(RUBRIQUES){id_rubrique}>
<BOUCLE_toplevelarticles(ARTICLES){id_rubrique IN #ID_RUBRIQUE,#_chap:ID_RUBRIQUE}>
#ID_ARTICLE
</BOUCLE_toplevelarticles>
</BOUCLE_chap>

-- Fil

Fil wrote:

Bizarre, chez moi la boucle que tu indiques fonctionne sans problème.

Ouf. Ce problème est difficile à cerner. Ça remonte plus loin:
Il s'agit d'un squelette inclus. La ligne qui l'appelle est celle-ci:

<INCLURE(rubtest.php3){id_article}{id_rubrique}{id_mot}{lang}>

- - - - -
A l'intérieur du squelette inclus, les boucles pertinentes sont :

<BOUCLE_principale(ARTICLES){id_article = #ENV{id_article,1}}>
<BOUCLE_chap(RUBRIQUES){id_rubrique=#ENV{id_rubrique}}{tout}{lang}>
  <BOUCLE_sharedchap(RUBRIQUES){id_mot}{id_secteur=586}{tout}{!lang_select}>
   <BOUCLE_lesarticles(ARTICLES){id_rubrique IN
#ID_RUBRIQUE,#_chap:ID_RUBRIQUE}{par titre}{!lang_select}>
    #ID_ARTICLE <br>
   </BOUCLE_lesarticles>
  </BOUCLE_sharedchap>
</BOUCLE_chap>
</BOUCLE_principale>

avec cette imbrication BOUCLE_lesarticles me donne juste article 1 (dont
id_rubrique = 0).
Si maintenant je *supprime* la boucle extérieure (BOUCLE_principale),
BOUCLE_lesarticles remarche convenablement.

Ce qui est étrange est que je peut mettre [(#ENV{id_rubrique})] n'importe où
là-dedans, avec ou sans la BOUCLE_principale, et elle affiche toujours la
bonne valeur (43). Mais d'une façon pour moi inexplicable la présence ou
absence de BOUCLE_principale change l'action de la BOUCLE_lesarticles.

Paolo

<BOUCLE_principale(ARTICLES){id_article = #ENV{id_article,1}}>
<BOUCLE_chap(RUBRIQUES){id_rubrique=#ENV{id_rubrique}}{tout}{lang}>
  <BOUCLE_sharedchap(RUBRIQUES){id_mot}{id_secteur=586}{tout}{!lang_select}>
   <BOUCLE_lesarticles(ARTICLES){id_rubrique IN #ID_RUBRIQUE,#_chap:ID_RUBRIQUE}{par titre}{!lang_select}>
    #ID_ARTICLE <br>
   </BOUCLE_lesarticles>
  </BOUCLE_sharedchap>
</BOUCLE_chap>
</BOUCLE_principale>

Whaou !

avec cette imbrication BOUCLE_lesarticles me donne juste article 1 (dont
id_rubrique = 0).
Si maintenant je *supprime* la boucle extérieure (BOUCLE_principale),
BOUCLE_lesarticles remarche convenablement.

Donc c'est plutôt {id_rubrique=#ENV{id_rubrique}} qui aurait changé de
comportement. Peux-tu expliquer à quoi sert ce critère ?

Dans le debugueur tu dois pouvoir trouver en quoi ce critère est compilé, ça
peut te donner une piste de réponse.

Ce qui est étrange est que je peut mettre [(#ENV{id_rubrique})] n'importe où
là-dedans, avec ou sans la BOUCLE_principale, et elle affiche toujours la
bonne valeur (43). Mais d'une façon pour moi inexplicable la présence ou
absence de BOUCLE_principale change l'action de la BOUCLE_lesarticles.

On est dans les arcanes :slight_smile:

-- Fil

OK, si je comprend bien, Paolo, tu es dans un squelette "rubrique" et tu souhaites faire une inclusion pour chaque article, c'est ca ?
Je n'ai pas bien regardé à fond le fonctionnement de #ENV, mais je crois que, si c'est bien ca, il ne te donne accès qu'aux variables passées en _POST, _GET ... pas au contexte_inclus (ou alors il y a des bugs dans certains cas), ce qui serait une bonne chose.
Ca permettrait d'utiliser les squelettes (en tout cas les boucles qui s'y trouvent) plus facilement en inclusion ou en direct.
Une meme boucle permettant d'utiliser l'id_article passé en GET en direct ou en parametre en inclusion.
Mais ca marche deja peut etre comme ca ... mais pas à tous les coups.

@++

Fil a écrit :

<BOUCLE_principale(ARTICLES){id_article = #ENV{id_article,1}}>
<BOUCLE_chap(RUBRIQUES){id_rubrique=#ENV{id_rubrique}}{tout}{lang}>

Fil wrote:

Donc c'est plutôt {id_rubrique=#ENV{id_rubrique}} qui aurait changé de
comportement. Peux-tu expliquer à quoi sert ce critère ?

Cela sert à attraper la valeur {id_rubrique} qui a été passée par
l'<INCLURE> qui ne correspond pas forcément à {id_rubrique} de la
BOUCLE_principale.

Dans le debugueur tu dois pouvoir trouver en quoi ce critère est compilé,
ça
peut te donner une piste de réponse.

Je vais regarder ... d'autres choses m'ont interrompu ce matin.

On est dans les arcanes :slight_smile:

Comme on aime :wink:
P.

Stephane wrote:

tu es dans un squelette "rubrique" et tu
souhaites faire une inclusion pour chaque article, c'est ca ?

Non. C'est un squelette article (qui fonctionne avec la CVS du 28 avril)
ici:
http://www.taize.fr/squelettes/t_artnorm.html
qui inclut
http://www.taize.fr/squelettes/ti_vmenu.html

Je n'ai pas bien regardé à fond le fonctionnement de #ENV, mais je crois
que, si c'est bien ca, il ne te donne accès qu'aux variables passées en
_POST, _GET ... pas au contexte_inclus (ou alors il y a des bugs dans
certains cas), ce qui serait une bonne chose.
Ca permettrait d'utiliser les squelettes (en tout cas les boucles qui
s'y trouvent) plus facilement en inclusion ou en direct.
Une meme boucle permettant d'utiliser l'id_article passé en GET en
direct ou en parametre en inclusion.
Mais ca marche deja peut etre comme ca ... mais pas à tous les coups.

Je ne suis pas sûr si tu parles de mon premier problème qui a été résolu. Ou
du deuxième qui est arrivé avec la résolution du premier?

merci en tout cas pour l'intérêt !
Paolo

Mais c'est aussi peut-être à

nous de renforcer la sécurité dans page.php3, plutôt que de laisser les gens
prendre des risques.

y a-t-il quelque part un topo sur page.php3, j'ai raté le début du fil

> Donc c'est plutôt {id_rubrique=#ENV{id_rubrique}} qui aurait changé de
> comportement. Peux-tu expliquer à quoi sert ce critère ?

Cela sert à attraper la valeur {id_rubrique} qui a été passée par
l'<INCLURE> qui ne correspond pas forcément à {id_rubrique} de la
BOUCLE_principale.

Ah oui, mais {lang} c'est la langue de l'article que tu viens de
sélectionner juste au dessus, pas celle du contexte. Ca fait peut-être un
résultat vide ?

-- Fil

rpapa wrote:

y a-t-il quelque part un topo sur page.php3, j'ai raté le début du fil

http://thread.gmane.org/gmane.comp.web.spip.devel/26926

Paolo

Fil wrote:

mais {lang} c'est la langue de l'article que tu viens de
sélectionner juste au dessus, pas celle du contexte.

C'est un peu compliqué, en effet. Donné la structure du site, je sais
d'avance que si la langue de l'article en cours (cette BOUCLE_principale ne
sert qu'à basculer #EXPOSER) est différent de {lang} passé dans l'<INCLURE>,
alors le squelette principal, dans lequel l'<INCLURE> se trouve, aura été
appelé avec $forcer_lang=1. Et la valeur de $forcer_lang se mantient à
travers le squelette inclus. Ce sera peut-être plus propre d'écrire
{lang=#ENV{lang}}.

Entretemps j'ai réussi à simplifier le test:

<BOUCLE_chap(RUBRIQUES){id_rubrique=43}>
   <BOUCLE_lesarticles1(ARTICLES){id_rubrique = #_chap:ID_RUBRIQUE}>
        #ID_ARTICLE <br>
   </BOUCLE_lesarticles>
</BOUCLE_chap>

ne marche pas en appel direct (sans <INCLURE>) !
BOUCLE_lesarticles donne:

SELECT articles.id_article, articles.lang
FROM spip_articles AS articles
WHERE (articles.id_rubrique = '')
    AND articles.statut='publie'

Dans la boucle _lesarticles:
{id_rubrique} et {id_rubrique=#ID_RUBRIQUE} marchent.
{id_rubrique=#_chap:ID_RUBRIQUE} et {id_rubrique IN #_chap:ID_RUBRIQUE} ne
marchent pas.

Voir la différence entre
http://www.taize.fr/rubtest2.php3 qui utilise encore la CVS du 25 avril.

et http://taize-devel.taize.asso.fr/rubtest2.php3 - la CVS d'aujourd'hui.
squelette : rubtest2.html

Paolo

Et voici la différence dans le debugueur entre la page qui marche

array("spip_articles AS articles"), # FROM
        array("articles.id_rubrique IN ('" .
addslashes($Pile[$SP]['id_rubrique']) . "')",

et celle qui ne marche pas:

array("spip_articles AS articles"), # FROM
        array("articles.id_rubrique IN ('" .
addslashes($Pile[$SP-1]['id_rubrique']) . "')",

juste ce "$Pile[$SP-1]" qui est différent (faux?), je pense.

Paolo

juste ce "$Pile[$SP-1]" qui est différent (faux?), je pense.

Oui, il est faux !
Essaie avec le nouveau patch, ça devrait coller (et ouvrir d'autres bugs,
j'espère, qu'on puisse continuer à s'amuser).

-- Fil

Fil wrote :

Essaie avec le nouveau patch, ça devrait coller

Tout est bien :slight_smile:
merci, Paolo