Caching.

Learn DXPR BuilderBuild pagesVolg een tutorial

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, was der Code cacht, welche Tags und Kontexte er nutzt, was sie invalidiert und was Sie nach einem Update von Hand leeren.

Das Builder-Feld

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

Metadaten Wert Wirkung
Cache-Kontext user.roles:authenticated Anonyme und authentifizierte 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 invalidiert das gerenderte Feld.
max-age 0 für alle authentifizierten Besucher Builder-Felder werden für eingeloggte Besucher nie im Dynamic Page Cache gecacht, weil das Render-Array benutzerspezifische drupalSettings trägt (E-Mail, CSRF-Tokens, Profil).

Für anonyme Besucher wird das Feld normal gecacht, sodass Internal Page Cache und Dynamic Page Cache Builder-Seiten ausliefern, ohne den Modulcode laufen zu lassen. Das Speichern im Builder speichert die Entität, sodass Drupal die Cache-Tags der Entität invalidiert 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üsselmeldung auf jeder Seite erscheint.

Die eigenen Adminformulare des Moduls invalidieren config:dxpr_builder.settings explizit: General Settings, AI, das Benutzerprofilformular und die Seiten- und Benutzervorlagenformulare.

Ansichten und Blöcke auf einer Seite

Blöcke und Ansichten liegen im gespeicherten HTML als leere az-cms-element-Platzhalter. Wenn das Feld rendert, lädt das Modul jeden Block oder jede Ansicht, rendert sie mit dem Core-Renderer und fügt die Ausgabe in das Feldmarkup ein. Die Libraries der Ansicht und ihre drupalSettings werden aufs Feld kopiert; ihre Cache-Metadaten blubbern durch den Renderer wie bei jedem Render-Array während eines Seitenrenderns.

Die Folge ist, dass die Zeilen einer Ansicht im gecachten Feld bleiben, bis eines der Cache-Tags der Ansicht invalidiert wird. Eine Ansicht mit zeitbasiertem Caching behält alte Zeilen ihre ganze Lebensdauer. Wenn Besucher veraltete Zeilen sehen:

  1. Öffnen Sie die Ansicht, klappen Sie Advanced auf und setzen Sie Caching auf Tag based. None stoppt den Dynamic Page Cache, aber der Internal Page Cache behält weiter ganze Seiten für anonyme Besucher.
  2. Speichern Sie die Ansicht. Das Speichern einer Ansicht invalidiert außerdem config:view_list, was die Ansichtslisten des Moduls für den Editor leert.
  3. Leeren Sie alle Caches.

Im Editor wird ein hinzugefügter oder geänderter Block bzw. eine Ansicht über /dxpr_builder/ajax geholt. Das Modul cacht diese Antwort nicht.

Interne Caches

Alle Einträge liegen im Standard-Cache-Bin (cache.default). Die Element-Picker-Caches tragen das Tag dxpr_builder:cms_elements plus die Listen-Cache-Tags der Entitätstypen, die sie listen, sodass sie sich selbst leeren, wenn sich diese Entitäten ändern.

Cache-ID Inhalt Geleert durch
dxpr_builder:cms_elements_blocks, dxpr_builder:cms_block_categories Blockliste und Blockkategorien für den Element-Picker Speichern oder Löschen eines Inhaltsblocks oder eines Webformulars (block_content_list, Webformular-Listen-Tags), Löschen der Einträge bei Deinstallation eines Moduls, drush cr
dxpr_builder:cms_disallowed_elements:<uid>:<roles hash> Blöcke, die dem aktuellen Konto nicht zur Verfügung stehen Dieselben Tags plus config:user.role.<role> für jede Rolle des Kontos
dxpr_builder:cms_elements_views, dxpr_builder:cms_view_elements_settings, dxpr_builder:cms_views_tags Ansichtanzeigen, deren Einstellungen und Kennungen für den Editor Speichern, Hinzufügen oder Löschen einer Ansicht (config:view_list), drush cr
dxpr_builder:button_styles Button-Stile für das Button-Element Tag dxpr_builder:cms_elements, drush cr
dxpr_builder_license_info Ergebnis des Lizenzstatus-Abrufs Läuft nach 24 Stunden ab, wenn autorisiert, sonst nach 30 Minuten (LICENSE_CHECK_INTERVAL, LICENSE_NOT_AUTHORIZED_INTERVAL); invalidiert, nachdem die Website eine Benutzeränderung an den Lizenzserver sendet
dxpr_builder_license_users Redaktionsliste vom Lizenzserver Läuft nach 24 Stunden ab; invalidiert, nachdem die Website eine Benutzeränderung an den Lizenzserver sendet
dxpr_builder_blacklisted Domain-Blocklist-Ergebnis Läuft nach einer Stunde ab, oder nach einer Minute, solange die Domain blockiert ist
dxpr_builder:jwt_decoded:<sha256 of the key> Dekodierter Produktschlüssel, ein Eintrag pro Schlüssel Tag config:dxpr_builder.settings

Theme-Utility-Klassen (dxpr_builder_classes in einem Theme- .info.yml) kommen aus Drupals gecachten Theme-Informationen, sodass eine Änderung drush cr braucht, bevor der Editor sie sieht. Icon-Set-Dateien (*.dxpr_icon_sets.yml) werden bei jedem Editor-Seitenaufruf gelesen, aber eine Library, die sie nennen, braucht drush cr wie jede neue Library.

Assets und Aggregierung

Die sechs Editor-Skripte sind entweder extern (Cloud) oder mit preprocess: FALSE deklariert, sodass die Aggregierung sie nie anfasst. Die Aggregierung gilt für die Hilfs-Libraries des Editors, etwa dxpr_builder/editor.core mit Sortable, und für die Besucherdateien (dxpr_builder/core, dxpr_builder/editor.frontend, die elements.*-Libraries und bootstrap_5). Zwei Symptome gehen auf den Aggregierungs-Cache zurück:

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

Was nach einem Update zu leeren ist

  1. Führen Sie die Datenbank-Updates aus und leeren Sie dann die Caches:

    drush updb -y
drush cr

    drush cr baut die Library-Definitionen des Builders neu, die der Modulversion und der Assetquelle folgen, die aggregierten Assetdateien und die internen Caches oben.

  2. Öffnen Sie als Mitglied der Redaktion eine Builder-Seite und speichern Sie sie. Das schreibt die Seite mit dem Markup der aktuellen Version und invalidiert ihre Entitäts-Tags.

  3. Purgen Sie hinter Varnish oder einem CDN die Builder-Seiten oder warten Sie, bis das Höchstalter abläuft; das Modul sendet keine Purge-Anfragen.

Wenn eine Seite Besuchern weiter alte Inhalte zeigt, siehe Probleme nach dem Aktualisieren.

Wie geht es weiter?