Version 19 — Novembre 2018 — JLuc
-* DEV : Améliorer l’onglet Cachelab avec un formulaire de saisie des arguments
-* DEV : Améliorer l’onglet Cachelab avec un formulaire de saisie des arguments. OU BIEN -* DEV : Intégrer Cachelab non comme un onglet à part, mais comme une 3 ligne dépliable des sélecteurs du haut de tableau de l’onglet « User caches » ? POUR COMMENCER, remplacer le bouton « Go » par « Liste » et ajouter « Del ».
-* Boucles avec critère {id_auteur}
contaminantes :
- Elles sont sessionnées, ce qui est « normal »
- Les autres noisettes de la page deviennent aussi sessionnées !
C’est critique. Il faut absolument éviter ces boucles.
ANALYSE : Est-ce que ça se passe toujours ou c’est lié aussi à d’autres conditions ? Où ça se passe t il dans le source ? Pourquoi ?
-* Les - Les caches sessionnés ont un « talon stub » = stub , cache sessionné creux, sans suffixe _ ni contenu html valeur de session , qui ne comprend comme métadonnées que l’invalideur < code>session=’’</code > session =’’ et < code>lastmodified</code >. lastmodified . Les talons ne sont pas des caches de squelette , mais des marqueur de sessionnage : ils servent uniquement à indiquer que les caches de ce squelette sont sessionnés ( cf D’aprés le [source de creer_cache->php#L233" class="spip_url spip_out auto" rel="nofollow external">https://core.spip.net/projects/spip/repository/entry/spip/ecrire/public/cacher.php#L233 ]. php#L233] Et alors , 1 ) il indique juste que c’est un autre cache qui contient le contenu et les métadonnées du squelette : celui avec le suffixe d’identifiant sessionné 2 ) « sa date indique la date de session . validite des caches sessionnés ».
Du coup, il n’est pas possible d’avoir un squelette parfois sessionné et parfois non sessionné selon l’endroit où il est appelé : il sera toujours considéré comme sessionné.
Il y a autant de talons qu’il y a de couples (squelette, contexte). Pour chacun de ces talons, il y a autant de caches qu’il y a de sessions. Xray propose des boutons pour, à partir d’un cache sessionné, accéder à la liste de tous les caches ayant le même talon.
ANALYSE : Comment est gérée l’arrivée d’un cache non sessionné alors qu’il fut sessionné avant ?
-* Quand - quand un modèle sessionné est inséré dans l’é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.
-* certains - certains caches ont un nom suffixé par /spip. : < code>cde542f8f0c4984dfe46444698b79-gis_json/spip</code > pour le cache de < code>plugins/auto/gis/v4 . Ce sont des pages directement appelées par spip.
php ? 44 . page=unepage :
- ...
8b79-gis_json/spip pour le cache de
gis_json.18/gis_json.html</code>
- <code >... >. 928-compte/spip
- ...f921a-saisies.css/spip
- ...fe22-mestrucs/spip
- ...a40f-backend/spip
Dans ces caches il y a [entetes]
=> Array ([Content-Type] => application/json; charset=utf-8... alors qu’il n’y a pas ça dans gis_truc ou gis_trucs, qui pourtant sont aussi des json. Serait ce à cause du header content-type qu’il y a le suffixe /spip ?
ANALYSE : toutes les pages appelées directement y sont elles ? Y a t il du coup 2 caches (identiques ?) : l’un pour l’appel via ?page= et l’autre (sans suffixe /spip) pour l’appel via INCLURE ?