Todo

• DEV : infos sur squelettes. Pour l’instant il y a des stats globales, par cache et il y a des facilités de filtrage par "talons" (=squelette sessionné x contexte).
  - Proposer des stats de hits par squelette + un boutonlien "mm squel" vers tous les caches de ce mm squelette (mais pas trop souvent : sur la ligne "squelette" du contenu des caches + pour les "talons" ?)
  - stats : indiquer combien de sessions il y a par squelette
  - liste : checkbox « Lister squelettes » (et non lister caches), qui n’affiche qu’une seule ligne pour tous les caches d’un même squelette. Avec boutonliens "talons", "caches"

• DEV stats sur les sessions et le sessionnement :
  - nombre de sessions

• DEV : dans les choix de filtrage par "type de cache", ajouter "pages" (présence d’un / à la fin de la clé du cache), "http", "https", "aliens", "vide", "périmé", "not_array"

• DEV : dans les choix d’affichages extra, ajouter #PRODUIRE ("produire_fond_statique")

• DEV : sauf si sélectionnés par filtrage, exclure les caches "aliens" (qui ont un autre préfixe de cache car ils ne concernent pas le site courant, ou concernent le site courant mais sur un autre port et ils ne sont pas pris en compte par memoization) ; exclure aussi les caches "périmés SPIP" et les caches qui n’existent plus pour APC même s’ils sont encore listés (mais pas tester "not array" car il faut lire les data).

• DEV : ajouter boutons-liens à droite :
  -  boutonlien "session" sur la ligne session dans les invalideurs
  -  boutonlien "mm squel" sur la ligne du squelette d’un contenu détaillé + sur les talons ?

• DEV : permettre de voir les données d’une session (savoir quel est l’id_auteur, l’email et le nom associés à un id_session ’14a6f056’). Pour cela, se servir de la noisette inclure/xray_marqueur_session.

• DEV : Améliorer l’onglet Cachelab avec un formulaire de saisie des arguments. OU BIEN 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 ».

• REBOOT : refaire tout, proprement (le code APCu utilisé à la base date de 1983 environ).

• DEV : valeurs corrigées des hits : « avant », les caches étaient filtrés par leur nom seulement, et le contenu n’était accédé que si on demandait à voir leur contenu. Depuis la détection des talons et les boutons « mm talon », le code a été allégé et le contenu des caches est désormais accédé à chaque rafraîchissement de la liste, même s’il n’y en a pas besoin. Du coup, la consultation de xray fait plus vite monter le taux de hit... mais ce taux ne reflète pas pour autant une meilleure gestion du cache pour le site public.
  Il serait possible de restituer une vision fidèle du taux de cache :
  - a) tenir dans un cache global durable (APC) le compte nbhitsxray des lectures dûes à XRay (et à CacheLab tant qu’on y est) depuis le dernier vidage des caches.
  - b) mémoriser ce décompte dans un champ de chaque cache au moment de sa création.
  - c) lors des affichages et calculs de taux de hits à l’instant t, on peut calculer le véritable nombre de hits pour les besoins du site : N(nombre total de hits du cache à t) - N(raffraichissements à t) + N(raffraichissements à création du cache).
  OU BIEN : idem mais sans champ supplémentaire dans chaque cache : avec une autre entrée globale durable = un tableau des entrées [date_création, nbhitsxray_init]

• ANALYSER : Le talon des caches sessionnés d’un squelette occupe le même espace (index de cache) que le cache non sessionné de ce squelette (pas de suffixe _). Or ils ne sont pas compatibles entre eux. C’est soit l’un, soit l’autre puisque leurs valeurs d’invalideurs[session] sont différentes (not set = non sessionné ; et vide = marqueur de sessionnement ).
  -  Une fois le talon créé, c’est le cache sessionné sans auth (avec suffixe _$) qui est également utilisé par la suite en guise de cache non sessionné. Mais quid si ça se passe dans l’autre sens ?
  -  Le talon n’est créé que s’il n’y a pas déjà un cache de même index. Mais s’il y en a déjà un, ce pourrait être lui-même ou le cache non sessionné de même emplacement. Donc, si le cache non sessionné est créé avant le premier cache sessionné, il n’y aura pas de talon, mais un cache non sessionné. Ce n’est pas grave pour l’écriture des caches sessionnés par creer_cache (car l’existence du talon est seulement testée pour savoir s’il faut le créer ou non), mais pour la lecture par public_cacher, c’est lui ( talon ou non sessionné) qu’on récupère d’abord, et c’est seulement s’il est sessionné (cas d’un vrai talon) qu’on cherche ensuite le cache sessionné... ce qui ne se passera donc pas si à la place du talon, un cache non sessionné a d’abord été écrit.
  -  Visiblement SPIP suppose qu’un squelette ne peut être à la fois sessionné dans certains contextes de compilation, et non sessionné dans d’autres contextes. Est-ce que cette supposition est justifiée : ne peut il à la fois y avoir un cache non sessionné et un cache sessionné pour un même squelette ?? Il semblerait que pourtant que ça soit possible, notamment car certains caches sessionnés contaminent les autres de même niveau (Voir test de contamination ) et que, placées dans une autre noizette, elles contamineraient même un cache non sessionné (forceraient son sessionnement). Ça se passerait alors ainsi :
  1) Cache vidé. Soit une noisette N non sessionnée. Son identifiant de cache est NNN. Ce serait aussi l’identifiant de cache du talon dans les cas où elle sessionnée.
  2) Cette noisette est d’abord inclue dans un contexte non contaminant, le cache non sessionné est donc créé : NNN. Ça baigne.
  3) Cette noisette est ensuite inclue dans un contexte contaminant avec un internaute logé. La lecture du cache NNN indique qu’elle n’est pas sessionnée, et c’est donc ce cache non sessionné qui est lu. La contamination a ainsi été annulée !
  A priori, ça ne cause pas de problème, sauf si la contamination est justifiée et qu’il faut réellement sessionner les caches contaminés (mais je vois pas pourquoi une telle contamination serait justifiée) ! Et de plus, les caches sessionnés par contamination ont été créés mais ne sont jamais utilisés.

Découvertes

-* BUG : Contamination des caches non sessionnés : Si dans un squelette ya une suite d’INCLURE non sessionnés avec au milieu d’eux un inclure sessionné, tous ceux aprés l’inclure sessionné seront aussi, indûement, sessionnés. (cf trac , carnet )

-* Les caches sessionnés ont un « talon » = stub, cache creux, sans suffixe _ ni contenu html, qui ne comprend comme métadonnées que l’invalideur session='' et 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 source : creer_cache et public_cacher). 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). 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.

-* Les squelettes appelés comme en tant que page d’une url ont un nom de cache qui se termine par /, tandis que le même squelette, appelé par un INCLURE, n’a pas ce / à la fin, même s’il a le même environnement. Y a t il une bonne raison ou bien il s’agit d’un bug ? De toute façon ce cas est exceptionnel.

-* 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 caches ont un nom suffixé par /spip. Ce sont des pages directement appelées par spip.php?page=unepage :
-  ...8b79-gis_json/spip pour le cache de gis_json.html
-  ...928-compte/spip
-  ...f921a-saisies.css/spip
-  ...fe22-mestrucs/spip
-  ...a40f-backend/spip

ANALYSE : cf generer_nom_fichier_cache dans memoization/public/cacher : ça vient de $page['contexte_implicite']['cache'].
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 ?