Bug entre le cache et #SESSION
Après pas mal de tests sur un site en SPIP 2.0.6, je me rends compte que certains blocs sont mis en cache avec le suffixe lié à la session de l'auteur alors qu'ils ne devraient pas.
En effet, si j'inclus un bloc dans la page qui utilise la balise session, tous les blocs que j'inclus ensuite vont avoir le même comportement lors de la sauvegarde dans le cache et avoir l'extension de la session dans leur nom de fichier, alors que ces blocs sont communs à tout le monde. En cherchant où signaler ce problème, je suis tombé sur ce message qui a l'air de confirmer ce que je pense:
http://article.gmane.org/gmane.comp.web.spip.user/142773/match=session+cache
Voila mon avis:
Pour savoir si on ajoute l'extension au nom de fichier dans le cache, on se base sur les variables $page['invalideurs']['session'] et $GLOBALS['cache_utilise_session']. Ces deux variables se renvoient la balle suivant que l'on soit dans parametrer.php ou assembler.php.
Le principe à respecter, si j'ai bien compris, est d'ajouter l'extension si le squelette en cours contient #SESSION, puis vider le marqueur une fois ce squelkette formé et sauvegardé.
dans parametrer.php:
// Si un modele contenait #SESSION, on note l'info dans $page if (isset($GLOBALS['cache_utilise_session'])) { $page['invalideurs']['session'] = $GLOBALS['cache_utilise_session']; unset($GLOBALS['cache_utilise_session']); }
dans assembler.php:
// Lever un drapeau (global) si le fond utilise #SESSION // a destination de public/parametrer if (isset($page['invalideurs']) AND isset($page['invalideurs']['session'])) $GLOBALS['cache_utilise_session'] = $page['invalideurs']['session'];
ainsi on pourrait penser que dans le process de calcul d'un squelette, on passe d'abord par le code de assembler, qui va prolonger le marqueur pour parametrer.php, qui a son tour vide la variable globale afin qu'elle n'affecte pas le reste de la page. Or j'ai bien l'impression que le process se fait dans le sens inverse, ainsi on a beau vider $GLOBALS['cache_utilise_session'], on réaffecte cette variable ensuite et cette variable va donc trainer tout le reste du processus SPIP et affecter les inclusions qui n'étaient à priori pas concernées.
Avec un site qui a beaucoup de blocs dans ses pages et beaucoup d'utilisateurs, comme c'est le cas d'Agoravox, l'effet peut encombrer le cache de manière exponentielle.