Découvertes faites avec XRay

Le talon des squelettes sessionnés

Savez vous que les Pour chacun de ces talons , il y a autant de caches sessionnés ont un «  talon  »  ? qu’il y a de sessions .
Ce Les caches sessionnés ont un «  talon, c’est un  » = stub, un garde-place , un cache creux, sans suffixe _ ni contenu html et , qui ne comprend comme métadonnées que l’invalideur session='' et lastmodified. Les talons sont gérés comme les caches mais ce ne sont pas des caches de squelette. Ce Les talons ne sont pas des caches de squelette , mais des marqueurs marqueur de sessionnage : ils servent uniquement à indiquer que les caches de ce squelette sont sessionnés ( cf source  : [creer_cache->https://core . Le source est là : [creer_cache->https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/cacher.php#L228] et [public_cacher->php#L352" class="spip_url spip_out auto" rel="nofollow external">https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/cacher.php#L352 ]. php#L352] ). Et alors, c’est un autre cache qui contient le contenu et les métadonnées du squelette : celui avec le suffixe d’identifiant de session.
_
Il y a autant de talons qu’il y a de couples (squelette, contexte). _ Xray permet de filtrer pour ne voir que les talons, et propose des liens pour accéder à la liste de tous les caches ayant le même talon.

Ces talons étant vides, c’est un autre cache qui contient le contenu sessionné et les métadonnées du squelette : cet autre cache a l’identifiant de session comme suffixe, ce qui permet de le reconnaître.
Xray permet de filtrer pour ne voir que les talons, et propose des liens pour accéder à la liste de tous les caches ayant le même talon.

Attention à l’explosion : il y a autant de talons qu’il y a de couples (squelette, contexte), et pour chacun de ces talons, il y a autant de caches qu’il y a de sessions. Si vous avez une noisette sessionnée, utilisée pour beaucoup d’objets et par beaucoup d’utilisateurs, il est possible que le cache sature et ne serve plus à rien.

Attention avec les compositions

les squelettes des compositions sont appelés par l’inclusion d’un autre squelette avec un argument composition en plus. Le cache résultant a le nom du squelette principal, mais la valeur du squelette associé (champ ’source’ du cache) est le squelette de la composition.

Dé-Dynamisation des inclusions dynamiques

L’inclusion d’un squelette statique dé-dynamise tous les caches des inclusions dynamiques faites par ce squelette.
Exemple : Si A #INCLUE B qui <INCLUE> C, alors C est en fait inclu statiquement dans B et donc dans A. Une conséquence est que si C est sessionné, alors B et A le sont aussi (confirmation par Cerdic).

Bug ou Feature ?
-  Ça me semble plus un bug qu’un feature. La gravité est C’est d’une importance limitée car on maîtrise en général bien les situations d’inclusion statique (et on peut pour les limiter).
-  Si c’est un feature ou si c’est pas possible de remettre ça en cause, on pourrait concevoir une nouvelle syntaxe permettant des inclusions superdynamiques, c’est à dire que ces inclusions ne seraient PAS dé-dynamisées lorsque le squelette incluant est inclu statiquement. Ça fait partie des pistes de développements futurs pour le plugin macrosession).

Quand un modèle sessionné est inséré dans le champ éditorial d’un objet

Quand un modèle sessionné est inséré dans le champ éditorial d’un objet, c’est le squelette affichant ce dernier qui est sessionné. L’inclusion du modèle est statique, pareil qu’avec #INCLURE. Le modèle n’a pas de cache du tout. Normalement, on peut avec SPIP3 spécifier une durée de cache pour le modele, mais avec SPIP 3.1.8 je ne vois aucun effet sur la durée du cache du squelette incluant donc je me demande si ça marche ou comment ça se passe.

Les squelettes appelés comme en tant que page d’une url

Les squelettes appelés comme en tant que page d’une url se distinguent de ceux appelé via un INCLURE : leur nom de cache se termine en plus par un suffixe. Au minimum ce suffixe est un simple /, mais d’autres chaines sont possibles. Le même squelette, appelé par un INCLURE, n’a pas ce / à la fin, même s’il a le même environnement.

Le suffixe semble être une sorte de slug relatif à l’url utilisée pour l’affichage de la page : par exemple /spip ou /1234 où 1234 est le N° de l’objet éditorial :
-  ...8b79-gis_json/spip pour le cache de gis_json.html
-  ...928-compte/spip
-  ...f921a-saisies.css/spip
-  ...fe22-mestrucs/spip
-  ...a40f-backend/spip
-  ...a12b-untruc/1234

Bug BUG SPIP (corrigé CORRIGÉ ) : Contamination des caches non sessionnés