Re : [spip-dev] Modif résultats #URL_BREVE

Dev
1

(étrange le titre du mail ;o)

En effet, faut que j'arrete le café moi !

Concernant mon pb, ça ne vient pas de la config PHP... Cela ne se produit
QUE pour un squelette utilisant des sessions, et sur les pages stockées

dans

le cache d'où nécessité de modifier la ligne générant les #BREVE_URL

Alors il faut que tu nous donnes un peu plus d'infos qu'on puisse reproduire
le bug (si bug il y a mais je ne vois vraiment pas pourquoi Spip ferait un
traitement different pour les breves ...)
Quelle version de SPIP, des infos sur ta config PHP et un bout de squelette
(le + simple possible, produisant cet effet chez toi).
Quand tu parles d'un "squelette avec session", tu entends quoi par la ?
Dans la page ou tu as le souci, il n'y a QUE les brèves qui aient l'id de
session ajouté ? d'autres liens générés par le meme "morceau de squelette"
sont propores ?

@++

2

If (âge_breve < âge_défini OR $_SESSION['T_as_payé'] == 'oui')
session_unset();
include page_contenant la breve ;
else
           session_unset();
include page_de_paiement ;

OK, ce n'est donc à mon avis pas lié aux brèves (si tu fait pareil avec des
articles tu auras sans doute le meme comportement).
Si je comprend bien ton approche, tu as une "page PHP" (et non pas un
squelette) qui fait un include d'un "squelette", c'est ca ?
Au nez, je dirai que c'est ton systeme d'inclusion qui pose probleme et qui,
de plus, n'utilise pas le cache alors qu'il le pourrait.
Peux tu réessayer en utilisant un squelette pour ta page appelante (mettre
le code dans toto.html et appeler toto.php3) et en utilisant INCLURE.
Je ne suis pas sur que ca resolve le probleme mais au moins tu devrais avoir
un comportement identique au premier appel et aux suivant (à mon avis, tu
risques d'avoir l'id de session dès le premier appel, le compilo
transformant les INCLURE en include ...)

Sinon, une piste peut etre :
ini_set('session.use_trans_sid', false);

Mais je ne sais pas ce que tu fais de ta session, alors c'est peut etre
encore pire avec ...

@++

3

OK, ce n'est donc à mon avis pas lié aux brèves (si tu fait pareil avec

des

articles tu auras sans doute le meme comportement).

Exact, toutes les URL générées par Spip (breves, articles, etc...) d'une
page breve.php3 sortie du cache, sont suivie d'un PHPSESSID. Le reste du
site est nickel.

Si je comprend bien ton approche, tu as une "page PHP" (et non pas un
squelette) qui fait un include d'un "squelette", c'est ca ?

J'ai un couple breve.php3/html qui contient le système d'inclusion (dans
l'html).
Ensuite, le systeme d'inclusion appelle un autre couple :
- si ok (présentation de la brève), breve_oui.php3/html
- si pas ok (présentation form audiotel), breve_non.php3/html
Ces 3 couples de page ont un cache à 3600.

Au nez, je dirai que c'est ton systeme d'inclusion qui pose probleme

C'est le moins que l'on puisse dire ;o)

et qui, de plus, n'utilise pas le cache alors qu'il le pourrait.

Sûr :sunglasses: ?
Je pensais plutôt au contraire... Les pages fraichement générées ont des
liens sans PHPSESSID...
Dès qu'une de ses pages sort du cache, les liens ont un PHPSESSID (normal ->
le PHPSESSID est celui du visiteur qui a généré la page avant qu'elle ne
soit stockée dans le cache)...

Peux tu réessayer en utilisant un squelette pour ta page appelante (mettre
le code dans toto.html et appeler toto.php3)

C'est déjà le cas :frowning:

et en utilisant INCLURE.

Difficile... Je passe d'autres variables perso dans l'include... Entre autre
pour éviter les accès directs à breve_oui.php3/html...

Je ne suis pas sur que ca resolve le probleme mais au moins tu devrais

avoir

un comportement identique au premier appel et aux suivant (à mon avis, tu
risques d'avoir l'id de session dès le premier appel, le compilo
transformant les INCLURE en include ...)

Sinon, une piste peut etre :
ini_set('session.use_trans_sid', false);

Oulà ! je vais essayé autre chose avant...

J'ai essayé un truc tout bète : un filtre sur $URL_BREVE composé d'un
explode sur '&PHPSESSID' de manière à sortir que la première moitié de
l'url... Mais rien... ce f***u PHPSESSID reste...

Si ça peut aider j'envoie une url en private...