Caché.
Una página de DXPR Builder es un array de renderizado de campo de Drupal con sus propios metadatos de caché, más unas pocas cachés internas que el módulo guarda para el editor y la comprobación de licencias. Esta página enumera lo que el código pone en caché, qué etiquetas y contextos usa, qué los invalida y qué debes limpiar a mano tras una actualización.
El campo del constructor
El formato de campo DXPR Builder fija estos metadatos de caché en cada campo del constructor:
| Metadatos | Valor | Efecto |
|---|---|---|
| Contexto de caché | user.roles:authenticated |
Las visitas anónimas y autenticadas reciben entradas de caché separadas. |
| Etiquetas de caché | Las etiquetas propias de la entidad, config:dxpr_builder.settings y config:language.entity.<langcode> para el idioma renderizado |
Guardar la entidad, guardar los ajustes del módulo o cambiar la configuración de idioma invalida el campo renderizado. |
max-age |
0 para cualquier usuario autenticado |
Los campos del constructor nunca quedan en la caché dinámica de página para personas con sesión iniciada, porque el array de renderizado lleva drupalSettings específicos de cada persona (correo, tokens CSRF, perfil). |
Para las visitas anónimas el campo se guarda en caché con normalidad, así que la caché interna de página y la caché dinámica de página sirven páginas del constructor sin ejecutar el código del módulo. Guardar en el constructor guarda la entidad, así que Drupal invalida las etiquetas de caché de la entidad como en cualquier otro guardado.
Cuando el editor está habilitado en el campo, el módulo añade
config:dxpr_builder.settings de nuevo. Con Asset source fijado en
Cloud y sin clave de producto configurada, también fija max-age en
0 para que el mensaje de clave de producto aparezca en cada página.
Los formularios de administración propios del módulo invalidan config:dxpr_builder.settings
de forma explícita: General Settings, AI, el formulario de perfil de usuario y
los formularios de plantillas de página y de usuario.
Vistas y bloques dentro de una página
Los bloques y las vistas se guardan en el HTML guardado como marcadores
az-cms-element vacíos. Cuando el campo se renderiza, el módulo
carga cada bloque o vista, lo renderiza con el renderizador del núcleo e
inserta la salida en el marcado del campo. Las bibliotecas de la vista y sus drupalSettings se copian
al campo; sus metadatos de caché emergen por el renderizador como
en cualquier array de renderizado construido durante un renderizado de página.
La consecuencia es que las filas de una vista quedan dentro del campo en caché hasta que se invalida una de las etiquetas de caché de la vista. Una vista con caché por tiempo conserva filas viejas toda su vida útil. Si las visitas ven filas obsoletas:
- Abre la vista, expande Advanced y fija Caching en Tag based. None detiene la caché dinámica de página, pero la caché interna de página aún guarda páginas completas para visitas anónimas.
- Guarda la vista. Guardar cualquier vista también invalida
config:view_list, lo que limpia las listas de vistas del módulo para el editor. - Limpia todas las cachés.
En el editor, un bloque o vista que añades o cambias se obtiene por
/dxpr_builder/ajax. El módulo no guarda en caché esa respuesta.
Cachés internas
Todas las entradas viven en el contenedor de caché predeterminado (cache.default). Las
cachés del selector de elementos llevan la etiqueta dxpr_builder:cms_elements
más las etiquetas de caché de lista de los tipos de entidad que enumeran, así que se
limpian solas cuando esas entidades cambian.
| ID de caché | Contenido | Quién lo limpia |
|---|---|---|
dxpr_builder:cms_elements_blocks, dxpr_builder:cms_block_categories |
Lista de bloques y categorías de bloques para el selector de elementos | Guardar o eliminar un bloque de contenido o un webform (block_content_list, etiquetas de lista de webforms), eliminar las entradas cuando se desinstala cualquier módulo, drush cr |
dxpr_builder:cms_disallowed_elements:<uid>:<roles hash> |
Bloques que la persona usuaria actual no puede usar | Las mismas etiquetas más config:user.role.<role> por cada uno de sus roles |
dxpr_builder:cms_elements_views, dxpr_builder:cms_view_elements_settings, dxpr_builder:cms_views_tags |
Pantallas de vistas, sus ajustes e identificadores para el editor | Guardar, añadir o eliminar cualquier vista (config:view_list), drush cr |
dxpr_builder:button_styles |
Estilos de botón para el elemento Button | Etiqueta dxpr_builder:cms_elements, drush cr |
dxpr_builder_license_info |
Resultado de la llamada de estado de licencia | Caduca tras 24 horas si está autorizada, 30 minutos si no (LICENSE_CHECK_INTERVAL, LICENSE_NOT_AUTHORIZED_INTERVAL); se invalida después de que el sitio envíe un cambio de usuario al servidor de licencias |
dxpr_builder_license_users |
Lista de personas que editan desde el servidor de licencias | Caduca tras 24 horas; se invalida después de que el sitio envíe un cambio de usuario al servidor de licencias |
dxpr_builder_blacklisted |
Resultado de la lista de dominios bloqueados | Caduca tras una hora, o un minuto mientras el dominio está bloqueado |
dxpr_builder:jwt_decoded:<sha256 of the key> |
Clave de producto decodificada, una entrada por clave | Etiqueta config:dxpr_builder.settings |
Las clases de utilidades del tema (dxpr_builder_classes en un
.info.yml del tema) vienen de la información de tema en caché de Drupal, así que un
cambio necesita drush cr antes de que el editor lo vea. Los archivos de conjuntos de iconos
(*.dxpr_icon_sets.yml) se leen en cada carga de página del editor, pero una
biblioteca que nombran necesita drush cr como cualquier biblioteca nueva.
Recursos y agregación
Los seis scripts del editor son externos (Cloud) o están declarados con
preprocess: FALSE, así que la agregación nunca los toca. La agregación
sí se aplica a las bibliotecas de ayuda del editor, como
dxpr_builder/editor.core con Sortable, y a los archivos para
visitas (dxpr_builder/core, dxpr_builder/editor.frontend, las
bibliotecas elements.* y bootstrap_5). Dos síntomas vienen de
la caché de agregación:
- El editor se rompe tras una actualización, o informa de
Sortable is not definedsolo con la agregación activada. Sigue El editor no aparece. - Las visitas no ven estilos ni iconos tras una actualización o un cambio de ajustes. Sigue Las visitas ven algo distinto.
Qué limpiar tras una actualización
-
Ejecuta las actualizaciones de base de datos y luego limpia las cachés:
drush updb -y drush crdrush crreconstruye las definiciones de biblioteca del constructor, que siguen la versión del módulo y el origen de recursos, los archivos agregados de recursos y las cachés internas de arriba. -
Abre una página del constructor como editor y guárdala. Esto escribe la página con el marcado de la versión actual e invalida sus etiquetas de entidad.
-
Detrás de Varnish o una CDN, purga las páginas del constructor o espera a que pase la edad máxima; el módulo no envía peticiones de purga.
Si una página aún muestra contenido viejo a las visitas, consulta Problemas tras actualizar.
¿Qué sigue?
- Rendimiento: lo que descarga cada página de visitas y de edición.
- Arquitectura: el código que renderiza, guarda y pone en caché un campo del constructor.
- Las visitas ven algo distinto: los síntomas de caché y sus soluciones.