Skip to content

Caching

A DXPR Builder page is a Drupal field render array with its own cache metadata, plus a handful of internal caches the module keeps for the editor and the licence check. This page lists what the code caches, which tags and contexts it uses, what invalidates them, and what to clear by hand after an update.

The builder field

The DXPR Builder field formatter sets this cache metadata on every builder field:

Metadata Value Effect
Cache context user.roles:authenticated Anonymous and authenticated visitors get separate cache entries.
Cache tags The entity's own tags, config:dxpr_builder.settings, and config:language.entity.<langcode> for the rendered language Saving the entity, saving the module settings, or changing the language configuration invalidates the rendered field.
max-age 0 for any authenticated user Builder fields are never cached by Dynamic Page Cache for logged-in users, because the render array carries user-specific drupalSettings (email, CSRF tokens, profile).

For anonymous visitors the field is cached normally, so Internal Page Cache and Dynamic Page Cache serve builder pages without running the module code. Saving in the builder saves the entity, so Drupal invalidates the entity's cache tags as for any other save.

When the editor is enabled on the field, the module adds config:dxpr_builder.settings again. With Asset source set to Cloud and no product key configured, it also sets max-age to 0 so the product key message shows on every page.

The module's own admin forms invalidate config:dxpr_builder.settings explicitly: General Settings, AI, the user profile form and the page and user template forms.

Views and blocks inside a page

Blocks and Views are stored in the saved HTML as empty az-cms-element placeholders. When the field renders, the module loads each block or View, renders it with the core renderer, and inserts the output into the field markup. The View's libraries and drupalSettings are copied onto the field; its cache metadata bubbles through the renderer as for any render array built during a page render.

The consequence is that a View's rows stay inside the cached field until one of the View's cache tags is invalidated. A View with time-based caching keeps old rows for its whole lifetime. If visitors see stale rows:

  1. Open the View, expand Advanced, and set Caching to Tag based. None stops Dynamic Page Cache, but Internal Page Cache still keeps whole pages for anonymous visitors.
  2. Save the View. Saving any View also invalidates config:view_list, which clears the module's lists of Views for the editor.
  3. Clear all caches.

In the editor, a block or View you add or change is fetched through /dxpr_builder/ajax. The module does not cache that response.

Internal caches

All entries live in the default cache bin (cache.default). The element picker caches carry the tag dxpr_builder:cms_elements plus the list cache tags of the entity types they list, so they clear themselves when those entities change.

Cache ID Content Cleared by
dxpr_builder:cms_elements_blocks, dxpr_builder:cms_block_categories Block list and block categories for the element picker Saving or deleting a content block or a webform (block_content_list, webform list tags), deleting the entries when any module is uninstalled, drush cr
dxpr_builder:cms_disallowed_elements:<uid>:<roles hash> Blocks the current user may not use The same tags plus config:user.role.<role> for each of the user's roles
dxpr_builder:cms_elements_views, dxpr_builder:cms_view_elements_settings, dxpr_builder:cms_views_tags View displays, their settings and identifiers for the editor Saving, adding or deleting any View (config:view_list), drush cr
dxpr_builder:button_styles Button styles for the Button element Tag dxpr_builder:cms_elements, drush cr
dxpr_builder_license_info Result of the licence status call Expires after 24 hours when authorised, 30 minutes otherwise (LICENSE_CHECK_INTERVAL, LICENSE_NOT_AUTHORIZED_INTERVAL); invalidated after the site sends a user change to the licence server
dxpr_builder_license_users Editor list from the licence server Expires after 24 hours; invalidated after the site sends a user change to the licence server
dxpr_builder_blacklisted Domain blocklist result Expires after one hour, or one minute while the domain is blocked
dxpr_builder:jwt_decoded:<sha256 of the key> Decoded product key, one entry per key Tag config:dxpr_builder.settings

Theme utility classes (dxpr_builder_classes in a theme .info.yml) come from Drupal's cached theme information, so a change needs drush cr before the editor sees it. Icon set files (*.dxpr_icon_sets.yml) are read on each editor page load, but a library they name needs drush cr like any new library.

Assets and aggregation

The six editor scripts are either external (Cloud) or declared with preprocess: FALSE, so aggregation never touches them. Aggregation does apply to the editor's helper libraries, such as dxpr_builder/editor.core with Sortable, and to the visitor-facing files (dxpr_builder/core, dxpr_builder/editor.frontend, the elements.* libraries and bootstrap_5). Two symptoms trace back to the aggregation cache:

What to clear after an update

  1. Run the database updates, then clear caches:

bash drush updb -y drush cr

drush cr rebuilds the builder's library definitions, which follow the module version and the asset source, the aggregated asset files, and the internal caches above. 2. Open one builder page as an editor and save it. This writes the page with the current release's markup and invalidates its entity tags. 3. Behind Varnish or a CDN, purge the builder pages or wait for the maximum age to pass; the module does not send purge requests.

If a page still shows old content for visitors, see Problems after updating.

What's next?

Something wrong or missing on this page? Report it or edit the page.