[spip-dev] 1.8b5 php entre inclure tout cassé

Dev
1

Hello,

Je viens de passer mon site de test en 1.8b5 et apparemment il y a quelque chose qui a radicalement changé.

J'utilise un peu de php pour faire qq petites choses.

Par exemple, dans un squelette menu.html j'incremente un compteur $menu_count.
Dans mon sommaire, je fait <INCLURE(menu.php)> et un peu plus loin un <?php echo $menu_count; ?>.

Et $menu_count est nul dans le sommaire alors qu'il ne l'est pas dans le menu. J'ai le même problème avec des variables perso qui se baladent entre inclure.

Jusqu'à maintenant, ca marchait tres bien, mais apparemment, le systeme d'inclure a changé et pers les variables entre squelette.

Est ce que c'est normal?
qu'est ce qui est préconisé pour echanger des variables php entre squelette à ce moment là? (je ne pense pas être le seul à avoir fait ce genre de chose tout de même)

Pierre

2

Je viens de passer mon site de test en 1.8b5 et apparemment il y a
quelque chose qui a radicalement changé.

En effet, c'est une conséquence inattendue de l'introduction de
inclure_page_lang() ; je corrige ça tout de suite.

-- Fil

3

Nickel, ca marche de nouveau.

Par contre avant, $lang suffisait pour récuperer la langue dans l'url, maintenant, il faut faire $_GET['lang'] ou [(#ENV{lang})]
Mais ca c'est un fonctionnement bien plus saint (même si ca enleve la compatibilité avec les squelettes un peu crados du passé :wink: alors je me plaint pas du tout.

Merci,

Pierre

4

Par contre avant, $lang suffisait pour récuperer la langue dans l'url,
maintenant, il faut faire $_GET['lang'] ou [(#ENV{lang})]

Détaille un peu le problème stp ?

Mais ca c'est un fonctionnement bien plus saint (même si ca enleve la
compatibilité avec les squelettes un peu crados du passé :wink: alors je me
plaint pas du tout.

Essayons de ne pas avoir de régression, si on peut l'éviter

-- Fil

5

> Par contre avant, $lang suffisait pour récuperer la langue dans l'url,
> maintenant, il faut faire $_GET['lang'] ou [(#ENV{lang})]

Détaille un peu le problème stp ?

Ah zut, le problème en fait ne se posait pas que pour les inclure. C'est
inc-public.php3 qui est tout cassé.

-- Fil

6

Ah zut, le problème en fait ne se posait pas que pour les inclure. C'est
inc-public.php3 qui est tout cassé.

Voici le problème : la nouvelle fonction calcule_header_et_page() a
l'intention de calculer la page, mais comme c'est une fonction, elle le fait
dans un cadre local, et non global.

Il y a deux solutions :

1) remettre l'équivalent de cette fonction dans inc-public.php3, comme
   c'était avant-hier, et résoudre autrement la question du 404 (c'était
   l'intention de cette transformation).

2) faire un truc très sale qui consiste à remettre les globales dans
   l'environnement local de la fonction en question ; ça n'est pas
   infaisable, mais c'est affreux :

       foreach ($GLOBALS as $var=>$val)
                $$var = &$GLOBALS[$var];

(non testé)

-- Fil

7

Voici le problème : la nouvelle fonction calcule_header_et_page() a
l'intention de calculer la page, mais comme c'est une fonction, elle le fait
dans un cadre local, et non global.

Il y a deux solutions :

1) remettre l'équivalent de cette fonction dans inc-public.php3, comme
   c'était avant-hier, et résoudre autrement la question du 404 (c'était
   l'intention de cette transformation).

En fait j'ai découpé la fonction calcule_header_et_page() en deux parties,
avec une séparation fonctionnelle à peu près lisible.

$page = calcule_header_et_page($fond, $delais)

renvoie le fichier calculé "brut de pomme", sans exécuter le php qu'il
contient, le cas échéant. Si ce fichier calculé est vide, et qu'on n'est pas
dans un cas bizarre (flag_preserver, debug, spip inclus dans un script,
etc), -> cette fonction envoie l'erreur 404.

Ensuite on revient donc dans inc-public, où l'on eval() la page calculée, et
on termine les traitements (passage au debuggueur, traitement de
var_recherche, et taches de fond).

Ca résoud notre bug, et ça allège tout de même inc-public, ce qui était je
crois un des buts d'Emmanuel dans cette opération. (?)

La seule différence avec avant, à part notre bug, c'est qu'il reste possible
de faire une page vide sans provoquer d'erreur 404, pour peu qu'on ait du
php dans les parties calculées du squelette.

Ainsi le squelette :
<?php $a = 7; ?><BOUCLE_xxx>....</BOUCLE_xxx>

Avec le modèle d'hier, si la boucle xxx ne renvoyait rien, la page 404
s'affichait ; avec le modèle que j'envoie, la prséence du morceau de php
silencieux fait qu'on ne déclenche pas d'erreur 404. Ca ne paraît pas
aberrant, mais c'est différent.

-- Fil