La configurazione

Cinque collection e un registro. `pages` è il layout; `sections` sono le sezioni riusabili; `blocks` i blocchi riusabili; `views` le viste; `menus` la navigazione. Il registro le espone insieme perché un progetto le installa in blocco.

Nessuna di queste contiene la FORMA: i viewMode e gli stili stanno negli store. È la divisione che permette di ridisegnare tutto senza una migrazione di database.

• collections/collectionPages.ts — le pagine: layout, stato, bozza, meta
• collections/collectionSections.ts — le sezioni riusabili
• collections/collectionBlocks.ts — i blocchi riusabili
• collections/collectionViews.ts — le viste: sorgente, query, mappatura
• collections/collectionMenus.ts — i menu, ricorsivi
• collections/uimsCollections.ts — il registro

Header e footer sono composizioni di slot: ogni slot ha un viewMode e i blocchi che contiene. I settings tengono la palette, i font e la configurazione generale. L’admin bar ha il proprio global perché la sua configurazione non è del sito ma dell’editor.

• globals/globalHeader.ts + globalFooter.ts — la cornice, come slot componibili
• globals/globalSettings.ts — palette, font, configurazione del sito
• globals/globalAdminBar.ts — la configurazione dell’editor

Ogni modifica invalida i tag della DAL. Quattro hook per quattro casi: una modifica in collection, una cancellazione (dove il documento non c’è più e i tag vanno costruiti da quello che resta), un global, un menu.

Il menu ha un hook proprio perché la sua modifica invalida anche le pagine che lo mostrano, che sono tutte quelle con un header — un caso che il tag del solo documento non coprirebbe.

• hooks/revalidateCollection.ts — dopo una modifica
• hooks/revalidateDelete.ts — dopo una cancellazione
• hooks/revalidateGlobalHook.ts — per i global
• hooks/revalidateMenu.ts — per i menu, che toccano ogni pagina
• hooks/form/beforeFormValidateHook.ts — la validazione dei form prima del salvataggio

Cinque file per i campi che compaiono in più posti. Il più denso è quello dello stato dell’istanza, che costruisce trigger e conseguenze e sa quali slice il blocco espone.

`fieldRoles` merita una riga: un campo che decide i permessi non può essere scrivibile da chi quei permessi non ha. Ci stava scritto `create/update: () => true`, e con una collection `users` senza `access` esplicito il risultato era un’escalation.

• fields/fieldsUiState.ts — il gruppo `uiState`: stato, trigger, conseguenze — costruito per blocco
• fields/fieldsView.ts — la configurazione di una vista: sorgente, query, mappatura dei campi
• fields/fieldsViewMode.ts + fieldsStyles.ts — forma e stili
• fields/fieldRoles.ts — il ruolo dell’utente, scrivibile solo da chi ha il ruolo
• access/byRole.ts — l’utente ha almeno uno dei ruoli richiesti?
• plugins/formBuilder.ts — la configurazione del form-builder di Payload