API CacheLab 2. Actions globales par type d’invalidation

Ce 2e niveau d’intervention avec CacheLab est plus global puisque cette API permet d’intercepter les invalidations du cache quelque soit leur origine dans le code de SPIP ou d’un plugin, via la surcharge de la fonction suivre_invalideur . Cette surcharge permet d’interpréter le signal d’invalidation reçu et d’appliquer une stratégie d’invalidation ciblée spécifiquement pour ce signal.

Signaux d’invalidation

Il y a un petit nombre de types de signaux d’invalidation. À chaque forme de signal est associé un typesignal :

-  Pour chaque type d’objet d’un site, il y a un signal d’invalidation de la forme id="objet/id_objet", qui est activé lorsqu’un crée, modifie ou détruit un objet de ce type. Par exemple id="article/1234". Par simplification on dit parfois aussi que le signal est alors article/1234. Dans cet exemple, le typesignal est article

-  Certains autres signaux correspondent à des événements plus qu’à des objets : recalcul lors d’une demande via var_mode=recalcul. Là, le typesignal est recalcul.

-  Certaines modifications d’objets génèrent un signal exotique : le signal favori/article/1234 indique qu’une invalidation est demandée pour cause de changement d’un favori portant sur l’article 1234. Dans le cas des favoris, un autre signal est également généré à la suite : favori/auteur/98 qui indique qu’un favori concernant l’auteur 98 a été créé, modifié ou supprimé. Dans cet exemple, le typesignal est favori

Rq : Les signaux d’invalidations sont systématiquement lancés par le noyau de SPIP et en général par les plugins de la zone, mais ne sont pas utilisés dans le noyau de SPIP. Ils ne servent que pour d’éventuels plugins comme CacheLab. Il n’est donc pas exclu que certains plugins provoquant des invalidations ne renseignent pas du tout ou pas correctement ce signal : dans ce cas il faudra les corriger pour qu’ils fournissent un signal suffisamment descriptif du motif et du contexte d’invalidation.

Fonctions d’invalidations globales circonstancielles

Pour utiliser ce 2e niveau d’API, le webmestre doit définir une stratégie d’invalidation pour chacun des types de signaux, au moyen d’une fonction dédiée dans laquelle il appellera les fonctions du 1er niveau que sont controler_invalideur et cachelab_cibler, avec le paramètre $action='del' et les conditions et options permettant d’invalider précisément les caches qui deviennent périmés.

Pour traiter le signal typesignal/..., il faut définir une fonction cachelab_suivre_invalideur_typesignal ($signal, $modif).
Les arguments sont :
-  $signal : le signal reçu.
-  $modif : a priori c’est true.

Cette fonction doit renvoyer true s’il faut ensuite poursuivre encore les traitements standards d’invalidation, ou false, si le signal a été entièrement traité et qu’il n’y a plus rien à faire.

Pour un signal unobjet/id_unobjet, cette fonction pourra par exemple appeler

cachelab_cibler('del', ['objet'=>$objet, 'id_objet'=>$id_objet]);

Cela invalidera tous les caches des squelettes ayant cet objet précis dans leur environnement. Il se peut, toutefois, que cela ne suffise pas, notamment lorsque cet objet peut figurer dans des listes : ces listes ne reçoivent pas les id des objets contenus mais des indications génériques (par exemple : « afficher 5 objets à partir du 10e »). Il faudra cibler plus largement, ou autrement.

On aura intérêt à bien ranger à part les squelettes des listes, dans un dossier « liste » par exemple, et alors il sera possible d’appeler :

cachelab_cibler('del', ['chemin'=>'liste']);

Exemples :

// gérer une demande d'invalidation concernant un point GIS
function cachelab_suivre_invalideur_gis($cond, $modif) {
	include_spip ('inc/cachelab');
	cachelab_cibler('del', ['chemin'=>'gis_']); // cibler gis_json, gis_article, etc
}

// gérer une demande d'invalidation concernant un document
function cachelab_suivre_invalideur_document($cond, $modif) {
	include_spip ('inc/cachelab');
	cachelab_cibler('del', ['chemin'=>'documents']);
}

Ce 2e niveau d’API permet donc de mettre en place une stratégie d’invalidation circonstanciée mais plus globale : chaque fonction répond à un signal d’invalidation spécifique, mais pour tout le site et quelque soit l’origine de l’invalidation de cet objet, et un traitement différent pour chaque formulaire ou autre bout de code invalidant.

Fonction decoder_invalideur

La fonction decoder_invalideur facilite la mise en place de fonctions globales contextuelles d’invalidation ciblée en décodant pour vous le signal d’invalidation. Cette fonction reçoit le signal et renvoie la valeur de l’identifiant de l’objet ayant généré le signal.

Elle reçoit 3 arguments
-  le signal
-  (optionnel) le type d’objet attendu (document, article, ...) si on le connaît à l’avance (ou vide sinon)
-  (optionnel) une variable passée en référence qui renverra le type d’objet réellement rencontré

Cette fonction sera utile pour cibler des caches précis lorsque nécessaire.
Exemple :

// gérer une demande d'invalidation issu d'un article
function cachelab_suivre_invalideur_article($signal, $modif) {
    include_spip ('inc/cachelab');
    $id_article = decoder_invalideur($signal, 'article');
    cachelab_cibler('del', ['chemin'=>'documents', 'objet'=>'article', 'id_article'=>$id_article]);
}

Discussion

Aucune discussion

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom