Caching.

Learn DXPR BuilderManage the siteNaar productie

Una pagina di DXPR Builder è un render array di campo Drupal con i suoi metadati di cache, più una manciata di cache interne tenute dal modulo per l’editor e il controllo licenze. Questa pagina elenca cosa il codice mette in cache, quali tag e contesti usa, cosa li invalida e cosa svuotare a mano dopo un aggiornamento.

Il campo builder

Il formatter del campo DXPR Builder imposta questi metadati di cache su ogni campo builder:

Metadati Valore Effetto
Contesto di cache user.roles:authenticated Visitatori anonimi e autenticati ricevono voci di cache separate.
Tag di cache I tag propri dell’entità, config:dxpr_builder.settings, e config:language.entity.<langcode> per la lingua renderizzata Salvare l’entità, salvare le impostazioni del modulo o cambiare la configurazione della lingua invalida il campo renderizzato.
max-age 0 per qualsiasi utente autenticato I campi builder non sono mai in cache in Dynamic Page Cache per gli utenti collegati, perché il render array contiene drupalSettings specifici per utente (email, token CSRF, profilo).

Per i visitatori anonimi il campo è in cache normalmente, quindi Internal Page Cache e Dynamic Page Cache servono pagine builder senza eseguire il codice del modulo. Salvare nel builder salva l’entità, quindi Drupal invalida i tag di cache dell’entità come per qualsiasi altro salvataggio.

Quando l’editor è attivo sul campo, il modulo aggiunge di nuovo config:dxpr_builder.settings. Con Asset source su Cloud e nessuna chiave prodotto configurata, imposta anche max-age a 0 così il messaggio della chiave prodotto compare su ogni pagina.

I form admin propri del modulo invalidano esplicitamente config:dxpr_builder.settings: General Settings, AI, il form del profilo utente e i form dei modelli di pagina e utente.

Viste e blocchi dentro una pagina

Blocchi e viste sono memorizzati nell’HTML salvato come segnaposto az-cms-element vuoti. Quando il campo è renderizzato, il modulo carica ogni blocco o vista, lo renderizza con il renderer del core e inserisce l’output nel markup del campo. Le librerie della vista e i drupalSettings sono copiati sul campo; i suoi metadati di cache risalgono tramite il renderer come per qualsiasi render array costruito durante il rendering di una pagina.

La conseguenza è che le righe di una vista restano dentro il campo in cache finché uno dei tag di cache della vista non è invalidato. Una vista con caching basato sul tempo mantiene vecchie righe per tutta la sua durata. Se i visitatori vedono righe obsolete:

  1. Apri la vista, espandi Advanced e imposta Caching a Tag based. None ferma Dynamic Page Cache, ma Internal Page Cache conserva comunque pagine intere per i visitatori anonimi.
  2. Salva la vista. Salvare qualsiasi vista invalida anche config:view_list, che svuota gli elenchi di viste del modulo per l’editor.
  3. Svuota tutte le cache.

Nell’editor, un blocco o una vista aggiunti o modificati sono recuperati tramite /dxpr_builder/ajax. Il modulo non mette in cache quella risposta.

Cache interne

Tutte le voci vivono nel bin di cache predefinito (cache.default). Le cache del selettore di elementi portano il tag dxpr_builder:cms_elements più i tag di cache di elenco dei tipi di entità elencati, quindi si svuotano da sole quando quelle entità cambiano.

ID di cache Contenuto Svuotata da
dxpr_builder:cms_elements_blocks, dxpr_builder:cms_block_categories Elenco blocchi e categorie di blocchi per il selettore di elementi Salvare o eliminare un blocco di contenuto o un webform (block_content_list, tag di elenco webform), eliminare le voci quando un modulo è disinstallato, drush cr
dxpr_builder:cms_disallowed_elements:<uid>:<roles hash> Blocchi che l’utente corrente non può usare Gli stessi tag più config:user.role.<role> per ciascuno dei ruoli dell’utente
dxpr_builder:cms_elements_views, dxpr_builder:cms_view_elements_settings, dxpr_builder:cms_views_tags Visualizzazioni di viste, loro impostazioni e identificatori per l’editor Salvare, aggiungere o eliminare qualsiasi vista (config:view_list), drush cr
dxpr_builder:button_styles Stili di pulsante per l’elemento Button Tag dxpr_builder:cms_elements, drush cr
dxpr_builder_license_info Risultato della chiamata di stato della licenza Scade dopo 24 ore se autorizzato, 30 minuti altrimenti (LICENSE_CHECK_INTERVAL, LICENSE_NOT_AUTHORIZED_INTERVAL); invalidato dopo che il sito invia una modifica utente al server delle licenze
dxpr_builder_license_users Elenco editor dal server delle licenze Scade dopo 24 ore; invalidato dopo che il sito invia una modifica utente al server delle licenze
dxpr_builder_blacklisted Risultato della blocklist di domini Scade dopo un’ora, o un minuto mentre il dominio è bloccato
dxpr_builder:jwt_decoded:<sha256 of the key> Chiave prodotto decodificata, una voce per chiave Tag config:dxpr_builder.settings

Le classi di utilità del tema (dxpr_builder_classes in un .info.yml del tema) vengono dalle informazioni di tema in cache di Drupal, quindi una modifica richiede drush cr prima che l’editor la veda. I file dei set di icone (*.dxpr_icon_sets.yml) sono letti a ogni caricamento di pagina dell’editor, ma una libreria da essi nominata richiede drush cr come qualsiasi nuova libreria.

Asset e aggregazione

I sei script dell’editor sono esterni (Cloud) o dichiarati con preprocess: FALSE, quindi l’aggregazione non li tocca mai. L’aggregazione si applica alle librerie ausiliarie dell’editor, come dxpr_builder/editor.core con Sortable, e ai file per i visitatori (dxpr_builder/core, dxpr_builder/editor.frontend, le librerie elements.* e bootstrap_5). Due sintomi risalgono alla cache di aggregazione:

Cosa svuotare dopo un aggiornamento

  1. Esegui gli aggiornamenti del database, poi svuota le cache:

    drush updb -y
    drush cr
    

    drush cr ricostruisce le definizioni di libreria del builder, che seguono la versione del modulo e la sorgente degli asset, i file asset aggregati e le cache interne sopra.

  2. Apri una pagina builder come editor e salvala. Questo scrive la pagina con il markup della release corrente e invalida i suoi tag di entità.

  3. Dietro Varnish o una CDN, elimina le pagine builder o attendi che passi l’età massima; il modulo non invia richieste di purge.

Se una pagina mostra ancora vecchi contenuti ai visitatori, vedi Problemi dopo l’aggiornamento.

Prossimi passi