Cache.

Apprendre DXPR BuilderGérer le sitePasser en production

Une page DXPR Builder est un tableau de rendu de champ Drupal avec ses propres métadonnées de cache, plus quelques caches internes que le module garde pour l’éditeur et la vérification de licence. Cette page liste ce que le code met en cache, les tags et contextes utilisés, ce qui les invalide, et ce qu’il faut vider à la main après une mise à jour.

Le champ builder

Le formateur de champ DXPR Builder pose ces métadonnées de cache sur chaque champ builder :

Métadonnée Valeur Effet
Contexte de cache user.roles:authenticated Les visiteurs anonymes et authentifiés reçoivent des entrées de cache séparées.
Tags de cache Les tags propres de l’entité, config:dxpr_builder.settings, et config:language.entity.<langcode> pour la langue rendue Enregistrer l’entité, enregistrer les réglages du module ou changer la configuration de langue invalide le champ rendu.
max-age 0 pour tout utilisateur authentifié Les champs builder ne sont jamais mis en cache par le Dynamic Page Cache pour les utilisateurs connectés, car le tableau de rendu transporte des drupalSettings propres à l’utilisateur (e-mail, jetons CSRF, profil).

Pour les visiteurs anonymes, le champ est mis en cache normalement, donc l’Internal Page Cache et le Dynamic Page Cache servent les pages du builder sans exécuter le code du module. Enregistrer dans le builder enregistre l’entité, donc Drupal invalide les tags de cache de l’entité comme pour tout autre enregistrement.

Quand l’éditeur est activé sur le champ, le module ajoute de nouveau config:dxpr_builder.settings. Avec Asset source réglé sur Cloud et sans clé de produit configurée, il met aussi max-age à 0 pour que le message de clé de produit s’affiche sur chaque page.

Les propres formulaires d’admin du module invalident config:dxpr_builder.settings explicitement : General Settings, AI, le formulaire de profil d’utilisateur et les formulaires de modèles de page et d’utilisateur.

Vues et blocs dans une page

Les blocs et les vues sont stockés dans le HTML enregistré comme des espaces réservés az-cms-element vides. Quand le champ est rendu, le module charge chaque bloc ou vue, le rend avec le moteur de rendu du cœur, et insère le résultat dans le balisage du champ. Les bibliothèques de la vue et ses drupalSettings sont copiés sur le champ ; ses métadonnées de cache remontent via le moteur de rendu comme pour tout tableau de rendu construit pendant un rendu de page.

Il s’ensuit que les lignes d’une vue restent dans le champ mis en cache jusqu’à ce que l’un des tags de cache de la vue soit invalidé. Une vue avec cache temporel garde de vieilles lignes pendant toute sa durée de vie. Si les visiteurs voient des lignes périmées :

  1. Ouvrez la vue, déployez Advanced, et réglez Caching sur Tag based. None arrête le Dynamic Page Cache, mais l’Internal Page Cache garde quand même des pages entières pour les visiteurs anonymes.
  2. Enregistrez la vue. Enregistrer n’importe quelle vue invalide aussi config:view_list, ce qui vide les listes de vues du module pour l’éditeur.
  3. Videz tous les caches.

Dans l’éditeur, un bloc ou une vue que vous ajoutez ou changez est récupéré via /dxpr_builder/ajax. Le module ne met pas cette réponse en cache.

Caches internes

Toutes les entrées vivent dans le compartiment de cache par défaut (cache.default). Les caches du sélecteur d’éléments portent le tag dxpr_builder:cms_elements plus les tags de liste des types d’entités qu’ils listent, donc ils se vident eux-mêmes quand ces entités changent.

Identifiant de cache Contenu Effacé par
dxpr_builder:cms_elements_blocks, dxpr_builder:cms_block_categories Liste des blocs et catégories de blocs pour le sélecteur d’éléments Enregistrer ou supprimer un bloc de contenu ou un webform (block_content_list, tags de liste des webforms), supprimer les entrées quand un module est désinstallé, drush cr
dxpr_builder:cms_disallowed_elements:<uid>:<roles hash> Blocs que l’utilisateur actuel ne peut pas utiliser Les mêmes tags plus config:user.role.<role> pour chacun des rôles de l’utilisateur
dxpr_builder:cms_elements_views, dxpr_builder:cms_view_elements_settings, dxpr_builder:cms_views_tags Affichages de vues, leurs réglages et identifiants pour l’éditeur Enregistrer, ajouter ou supprimer n’importe quelle vue (config:view_list), drush cr
dxpr_builder:button_styles Styles de boutons pour l’élément Button Tag dxpr_builder:cms_elements, drush cr
dxpr_builder_license_info Résultat de l’appel de statut de licence Expire après 24 heures avec autorisation, 30 minutes sinon (LICENSE_CHECK_INTERVAL, LICENSE_NOT_AUTHORIZED_INTERVAL) ; invalidé après que le site envoie un changement d’utilisateur au serveur de licences
dxpr_builder_license_users Liste des contributeurs depuis le serveur de licences Expire après 24 heures ; invalidé après que le site envoie un changement d’utilisateur au serveur de licences
dxpr_builder_blacklisted Résultat de la liste de blocage de domaines Expire après une heure, ou une minute tant que le domaine est bloqué
dxpr_builder:jwt_decoded:<sha256 of the key> Clé de produit décodée, une entrée par clé Tag config:dxpr_builder.settings

Les classes utilitaires du thème (dxpr_builder_classes dans un .info.yml de thème) viennent des informations de thème mises en cache de Drupal, donc un changement nécessite drush cr avant que l’éditeur ne le voie. Les fichiers de jeux d’icônes (*.dxpr_icon_sets.yml) sont lus à chaque chargement de page de l’éditeur, mais une bibliothèque qu’ils nomment nécessite drush cr comme toute nouvelle bibliothèque.

Ressources et agrégation

Les six scripts de l’éditeur sont soit externes (Cloud), soit déclarés avec preprocess: FALSE, donc l’agrégation ne les touche jamais. L’agrégation s’applique aux bibliothèques auxiliaires de l’éditeur, comme dxpr_builder/editor.core avec Sortable, et aux fichiers côté visiteur (dxpr_builder/core, dxpr_builder/editor.frontend, les bibliothèques elements.* et bootstrap_5). Deux symptômes remontent au cache d’agrégation :

Ce qu’il faut vider après une mise à jour

  1. Exécutez les mises à jour de base de données, puis videz les caches :

    drush updb -y
drush cr

    drush cr reconstruit les définitions de bibliothèques du builder, qui suivent la version du module et la source des ressources, les fichiers de ressources agrégés, et les caches internes ci-dessus.

  2. Ouvrez une page du builder en contributeur et enregistrez-la. Cela écrit la page avec le balisage de la version actuelle et invalide ses tags d’entité.

  3. Derrière Varnish ou un CDN, purgez les pages du builder ou attendez la fin de l’âge maximal ; le module n’envoie pas de demandes de purge.

Si une page montre toujours l’ancien contenu aux visiteurs, voir Problèmes après mise à jour.

Et ensuite ?