Caching.

DXPR Builder lernenWebsite verwaltenIm Live-Betrieb

Eine DXPR-Builder-Seite ist ein Drupal-Feld-Render-Array mit eigenen Cache-Metadaten, plus einer Handvoll interner Caches, die das Modul für den Editor und die Lizenzprüfung hält. Diese Seite listet auf, was der Code zwischenspeichert, welche Tags und Kontexte er nutzt, was sie ungültig macht und was Sie nach einem Update von Hand leeren.

Das Builder-Feld

Der Feld-Formatierer DXPR Builder setzt diese Cache-Metadaten auf jedes Builder-Feld:

Metadaten	Wert	Wirkung
Cache-Kontext	`user.roles:authenticated`	Anonyme und angemeldete Besucher erhalten getrennte Cache-Einträge.
Cache-Tags	Die eigenen Tags der Entität, `config:dxpr_builder.settings`, und `config:language.entity.<langcode>` für die gerenderte Sprache	Das Speichern der Entität, das Speichern der Moduleinstellungen oder das Ändern der Sprachkonfiguration macht das gerenderte Feld ungültig.
`max-age`	`0` für alle Angemeldeten	Builder-Felder werden für Angemeldete nie vom Dynamic Page Cache zwischengespeichert, weil das Render-Array benutzerspezifische `drupalSettings` trägt (E-Mail, CSRF-Tokens, Profil).

Für anonyme Besucher wird das Feld normal zwischengespeichert, daher liefern Internal Page Cache und Dynamic Page Cache Builder-Seiten aus, ohne den Modulcode laufen zu lassen. Das Speichern im Builder speichert die Entität, daher macht Drupal die Cache-Tags der Entität ungültig wie bei jedem anderen Speichern.

Wenn der Editor auf dem Feld aktiviert ist, fügt das Modul config:dxpr_builder.settings erneut hinzu. Mit Asset source auf Cloud und ohne konfigurierten Produktschlüssel setzt es max-age außerdem auf 0, sodass die Produktschlüssel-Meldung auf jeder Seite erscheint.

Die eigenen Admin-Formulare des Moduls machen config:dxpr_builder.settings explizit ungültig: General Settings, AI, das Benutzerprofil-Formular sowie die Seiten- und Benutzervorlagen-Formulare.

Ansichten und Blöcke in einer Seite

Blöcke und Ansichten liegen im gespeicherten HTML als leere az-cms-element-Platzhalter. Beim Rendern des Felds lädt das Modul jeden Block bzw. jede Ansicht, rendert ihn bzw. sie mit dem Core-Renderer und fügt die Ausgabe in das Feld-Markup ein. Die Bibliotheken der Ansicht und ihre drupalSettings werden auf das Feld kopiert; ihre Cache-Metadaten steigen durch den Renderer auf wie bei jedem Render-Array, das während eines Seiten-Renders gebaut wird.

Die Folge ist, dass die Zeilen einer Ansicht im zwischengespeicherten Feld bleiben, bis eines der Cache-Tags der Ansicht ungültig wird. Eine Ansicht mit zeitbasiertem Caching behält alte Zeilen über ihre gesamte Lebensdauer. Wenn Besucher veraltete Zeilen sehen:

Öffnen Sie die Ansicht, klappen Sie Advanced auf und setzen Sie Caching auf Tag based. None stoppt Dynamic Page Cache, aber Internal Page Cache hält ganze Seiten für anonyme Besucher weiterhin vor.
Speichern Sie die Ansicht. Das Speichern jeder Ansicht macht außerdem config:view_list ungültig, was die Ansichtslisten des Moduls für den Editor leert.
Leeren Sie alle Caches.

Im Editor werden ein hinzugefügter oder geänderter Block bzw. eine hinzugefügte oder geänderte Ansicht über /dxpr_builder/ajax abgerufen. Das Modul speichert diese Antwort nicht zwischen.

Interne Caches

Alle Einträge leben im Standard-Cache-Bin (cache.default). Die Elementauswahl-Caches tragen das Tag dxpr_builder:cms_elements plus die Listen-Cache-Tags der Entitätstypen, die sie auflisten, sodass sie sich bei Änderungen dieser Entitäten selbst leeren.

Cache-ID	Inhalt	Geleert durch
`dxpr_builder:cms_elements_blocks`, `dxpr_builder:cms_block_categories`	Blockliste und Blockkategorien für die Elementauswahl	Speichern oder Löschen eines Inhaltsblocks oder Webformulars (`block_content_list`, Webformular-Listen-Tags), Löschen der Einträge bei Deinstallation irgendeines Moduls, `drush cr`
`dxpr_builder:cms_disallowed_elements:<uid>:<roles hash>`	Blöcke, die aktuell Bearbeitende nicht nutzen dürfen	Dieselben Tags plus `config:user.role.<role>` für jede Rolle der bearbeitenden Person
`dxpr_builder:cms_elements_views`, `dxpr_builder:cms_view_elements_settings`, `dxpr_builder:cms_views_tags`	Anzeige-Ansichten, ihre Einstellungen und Kennungen für den Editor	Speichern, Hinzufügen oder Löschen jeder Ansicht (`config:view_list`), `drush cr`
`dxpr_builder:button_styles`	Schaltflächenstile für das Button-Element	Tag `dxpr_builder:cms_elements`, `drush cr`
`dxpr_builder_license_info`	Ergebnis des Lizenzstatus-Aufrufs	Läuft nach 24 Stunden ab, wenn autorisiert, sonst nach 30 Minuten (`LICENSE_CHECK_INTERVAL`, `LICENSE_NOT_AUTHORIZED_INTERVAL`); ungültig, nachdem die Website eine Benutzeränderung an den Lizenzserver sendet
`dxpr_builder_license_users`	Redaktionsliste vom Lizenzserver	Läuft nach 24 Stunden ab; ungültig, nachdem die Website eine Benutzeränderung an den Lizenzserver sendet
`dxpr_builder_blacklisted`	Ergebnis der Domain-Blockliste	Läuft nach einer Stunde ab, oder nach einer Minute, solange die Domain blockiert ist
`dxpr_builder:jwt_decoded:<sha256 of the key>`	Decodierter Produktschlüssel, ein Eintrag pro Schlüssel	Tag `config:dxpr_builder.settings`

Theme-Dienstklassen (dxpr_builder_classes in einer .info.yml des Themes) stammen aus Drupals zwischengespeicherten Theme-Informationen, daher braucht eine Änderung drush cr, bevor der Editor sie sieht. Icon-Set-Dateien (*.dxpr_icon_sets.yml) werden bei jedem Editor-Seitenaufruf gelesen, aber eine Bibliothek, die sie nennen, braucht drush cr wie jede neue Bibliothek.

Assets und Aggregation

Die sechs Editor-Skripte sind entweder extern (Cloud) oder mit preprocess: FALSE deklariert, daher rührt Aggregation sie nie an. Aggregation greift bei den Helfer-Bibliotheken des Editors, etwa dxpr_builder/editor.core mit Sortable, und bei den besucherseitigen Dateien (dxpr_builder/core, dxpr_builder/editor.frontend, die elements.*-Bibliotheken und bootstrap_5). Zwei Symptome gehen auf den Aggregations-Cache zurück:

Der Editor bricht nach einem Update ab, oder meldet Sortable is not defined nur bei eingeschalteter Aggregation. Folgen Sie Der Editor erscheint nicht.
Besucher sehen nach einem Update oder einer Einstellungsänderung keine Stile oder Icons. Folgen Sie Besucher sehen etwas anderes.

Was nach einem Update zu leeren ist

Führen Sie die Datenbank-Updates aus, dann leeren Sie die Caches:
```
drush updb -y
drush cr
```
drush cr baut die Builder-Bibliotheksdefinitionen neu auf, die der Modulversion und der Asset-Quelle folgen, die aggregierten Asset-Dateien sowie die internen Caches oben.
Öffnen Sie eine Builder-Seite als bearbeitende Person und speichern Sie sie. Dies schreibt die Seite mit dem Markup des aktuellen Releases und macht ihre Entitäts-Tags ungültig.
Hinter Varnish oder einem CDN leeren Sie die Builder-Seiten oder warten, bis das Maximalalter verstreicht; das Modul sendet keine Purge-Anfragen.

Wenn eine Seite Besuchern weiterhin alte Inhalte zeigt, siehe Probleme nach dem Update.

Wie geht es weiter?

Performance: was jede Besucher- und Editorseite lädt.
Architektur: der Code, der ein Builder-Feld rendert, speichert und zwischenspeichert.
Besucher sehen etwas anderes: die Cache-bezogenen Symptome und ihre Lösungen.