Caching.
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:
- 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.
- Salva la vista. Salvare qualsiasi vista invalida anche
config:view_list, che svuota gli elenchi di viste del modulo per l’editor. - 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:
- L’editor si rompe dopo un aggiornamento, o riporta
Sortable is not definedsolo con aggregazione attiva. Segui L’editor non compare. - I visitatori non vedono stili o icone dopo un aggiornamento o una modifica delle impostazioni. Segui I visitatori vedono qualcosa di diverso.
Cosa svuotare dopo un aggiornamento
-
Esegui gli aggiornamenti del database, poi svuota le cache:
drush updb -y drush crdrush crricostruisce 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. -
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à.
-
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
- Performance per ciò che ogni pagina di visitatori ed editor scarica.
- Architettura per il codice che renderizza, salva e mette in cache un campo builder.
- I visitatori vedono qualcosa di diverso per i sintomi legati alla cache e le loro soluzioni.