Page Layouts

I Page Layouts sono definizioni a livello di installazione che gestiscono la scelta della struttura pubblica esterna e i wrapper degli slot gestiti delle pagine.

Ambito della V1

  • Percorso di amministrazione: Admin -> System -> Page Layouts
  • Accesso: solo super_admin
  • La V1 supporta elenco, creazione, modifica, attivazione, disattivazione, ordinamento, CRUD dei Page Layout Slots gestiti, confronto degli slot in Edit Page e applicazione sicura degli slot mancanti
  • La V1 non supporta l'eliminazione dei layout di sistema
  • In questa release le pagine continuano a salvare l'handle del layout selezionato in pages.settings.public_shell per retrocompatibilità
  • I campi visibili del Page Layout sono Name, Handle, Description, Status, Sort Order e Body Class
  • Shell Type, Slot Schema JSON e Wrapper Schema JSON sono campi di compatibilità deprecati e non fanno più parte del modulo di amministrazione
  • Slot Schema JSON e Wrapper Schema JSON grezzi non sono più il modello di modifica dell'amministrazione

Layout integrati

  • default / Default Layout: struttura standard della pagina pubblica
  • docs / Docs Layout: struttura per la documentazione con mappatura delle regioni header, sidebar, main e footer

Questi layout integrati restano compatibili con pagine, importazioni, esportazioni e rendering pubblico precedenti.

Ogni layout integrato genera inoltre Page Layout Slots gestiti:

  • default: header, main, sidebar, footer
  • docs: header, sidebar, main, footer

Come funziona il rendering

  • Una pagina salva un handle di Page Layout in public_shell
  • A runtime quell'handle viene risolto in un Page Layout gestito quando esiste
  • Il Page Layout risolto può fornire un body_class validato all'elemento <body> pubblico
  • A runtime i wrapper degli slot vengono risolti dai page_layout_slots relazionali quando disponibili
  • Ogni Page Layout Slot fa riferimento a una riga SlotType pubblicata del CMS e definisce metadati del wrapper quali elemento, id, classi e frammenti di wrapper attendibili
  • Se i Page Layout Slots relazionali non sono disponibili, le definizioni di ripiego integrate mantengono stabile il rendering di default e docs

Nella V1 i layout personalizzati continuano a riutilizzare il comportamento della struttura pubblica default o docs esistente. Per compatibilità, il runtime deduce quel comportamento in modo conservativo dalle definizioni degli slot gestiti.

Page Layout Slots gestiti

I Page Layout Slots sono i record di regione gestiti associati a un Page Layout.

  • Percorso di amministrazione: Admin -> System -> Page Layouts -> Edit -> Page Layout Slots
  • Gli Slot Types sono il catalogo per aggiungere Page Layout Slots
  • Ogni Page Layout Slot salva slot_type_id, slot_name, label, description, html_element, html_id, html_classes, before_html, start_html, end_html, after_html, is_required, is_active, is_system e sort_order
  • La modifica in amministrazione raggruppa questi campi in Slot Identity, Wrapper Markup, Advanced Trusted Layout HTML e Status / Ordering
  • La validazione consente solo id HTML sicuri, classi sicure separate da spazi e frammenti di wrapper attendibili, e rifiuta script, attributi di evento, javascript:, iframe, object ed embed
  • I layout di sistema mantengono stabile la mappatura dei loro slot di sistema: i Page Layout Slots di sistema non permettono di cambiare il nome dello slot sottostante né lo Slot Type
  • I Page Layout Slots non di sistema e non obbligatori possono essere rimossi
  • CSS Classes si aspetta token di classe separati da spazi
  • Le classi del wrapper possono includere indicazioni di layout come wb-sidebar, wb-dashboard-main o wb-stack quando sono adatte al layout selezionato
  • Il comportamento sticky della Navbar pubblica dovrebbe provenire dalla primitiva wb-navbar inclusa, non da regole sticky di intestazione a livello di sito
  • Quando uno slot di intestazione pubblica predefinito contiene solo un blocco Navbar, il CMS promuove il wrapper dello slot alla radice nav.wb-navbar, così la Navbar resta sticky senza CSS specifico del sito
  • Before Slot HTML viene renderizzato prima del wrapper dello slot
  • Slot Start HTML viene renderizzato dentro il wrapper, prima dei blocchi
  • Slot End HTML viene renderizzato dentro il wrapper, dopo i blocchi
  • After Slot HTML viene renderizzato dopo il wrapper dello slot
  • L'HTML di layout attendibile avanzato serve solo per markup di layout adiacente al wrapper, non per gli script

Confronto e applicazione in Edit Page

  • Edit Page mostra ora una scheda Page Layout Slots vicino alla gestione degli slot
  • La scheda confronta i Page Layout Slots gestiti attivi del Page Layout selezionato con i Page Slots attuali della pagina
  • Il confronto riporta almeno:
  • i Layout Slots definiti dal Page Layout selezionato
  • i Page Slots già presenti nella pagina
  • i Layout Slots mancanti
  • i Page Slots aggiuntivi non definiti dal Page Layout selezionato
  • i Page Slots disattivati
  • i Page Slots basati su uno Shared Slot
  • Add Missing Layout Slots compare solo quando esistono Layout Slots mancanti
  • L'azione è esplicita. Salvare le normali impostazioni della pagina non sincronizza gli slot in silenzio.

Regole di sicurezza

  • Add Missing Layout Slots crea nella pagina corrente solo i Page Layout Slots attivi mancanti
  • Non elimina i Page Slots aggiuntivi
  • Non elimina blocchi
  • Non modifica il page_slots.source_type esistente
  • Non cancella lo shared_slot_id esistente
  • Non attiva automaticamente i Page Slots disattivati
  • Non riordina né riscrive in silenzio i Page Slots esistenti
  • I Page Slots aggiuntivi vengono conservati e segnalati per sicurezza, anche se il Page Layout selezionato non li definisce
  • La compatibilità degli Shared Slot resta esatta in base all'handle public_shell salvato

Valori predefiniti delle nuove pagine

  • Le nuove pagine usano, quando possibile, i Page Layout Slots gestiti attivi del Page Layout selezionato
  • Il ripiego legacy slot_schema resta solo come ripiego sicuro di compatibilità quando le definizioni di slot gestiti relazionali o integrate non sono disponibili
  • Le nuove pagine non dovrebbero obbligare gli amministratori ad aggiungere manualmente gli slot standard dopo aver scelto un Page Layout

Modifiche del Page Layout su pagine esistenti

  • Cambiare il Page Layout selezionato su una pagina esistente non elimina né riscrive automaticamente gli slot durante un salvataggio normale
  • Dopo il salvataggio, Edit Page mostra il confronto aggiornato affinché gli editor possano esaminare in sicurezza gli slot mancanti o in eccesso
  • La release attuale preferisce intenzionalmente l'Add Missing Layout Slots esplicito alla mutazione automatica

Body Class

  • Body Class è un elenco opzionale di token separati da spazi aggiunto al <body> pubblico
  • I valori integrati generati sono attualmente layout-default e layout-docs
  • Il rendering pubblico mantiene la classe base wb-public-body e aggiunge le classi body del Page Layout quando disponibili
  • Il CSS specifico del layout può puntare a combinazioni come body.layout-docs più gli id e le classi di slot definiti dai Page Layout Slots
  • Preferite un blocco Navbar per le intestazioni pubbliche sticky; il CMS promuove gli slot di intestazione predefiniti con una sola Navbar alla radice nav.wb-navbar, così WebBlocks UI controlla l'offset sticky e l'impilamento

Confini di responsabilità

  • Il Page Layout è responsabile della scelta della struttura pubblica esterna
  • Il Page Layout è responsabile anche dei token di classe body pubblici di quella struttura
  • I Page Layout Slots sono responsabili dei metadati e dell'ordine dei wrapper di regione
  • I Page Layout Slots sono responsabili dell'elemento wrapper pubblico, del suo id, delle sue classi e dell'HTML attendibile opzionale adiacente al wrapper di ogni regione
  • I nomi degli slot sono responsabili della semantica del wrapper di regione, come header, main, sidebar e footer
  • I blocchi sono responsabili del contenuto renderizzato dentro quei wrapper
  • Il comportamento sticky della navbar resta di competenza di .wb-navbar di WebBlocks UI, non dei Page Layouts del CMS

Layout sconosciuti o mancanti

  • Le pagine esistenti non vengono migrate via da public_shell
  • Gli handle di layout sconosciuti restano memorizzati così come sono
  • La modifica in amministrazione resta sicura mostrando l'handle legacy attuale come opzione conservata
  • Il rendering pubblico ripiega in sicurezza invece di andare in errore
  • Nella V1 gli handle sconosciuti ripiegano in sicurezza sul comportamento di runtime predefinito

Compatibilità con gli Shared Slot

Nella V1 la compatibilità degli Shared Slot resta conservativa.

  • Le schermate di amministrazione degli Shared Slot presentano ora questo vincolo come Page Layout, mentre il campo di compatibilità memorizzato resta public_shell per retrocompatibilità in questa release
  • È richiesta la corrispondenza esatta dell'handle public_shell quando uno Shared Slot imposta public_shell
  • Un public_shell vuoto resta generico
  • Un handle di layout personalizzato che riutilizza il comportamento di runtime in stile docs non corrisponde automaticamente agli Shared Slot vincolati a docs
  • Aggiungere i Layout Slots mancanti crea nuovi Page Slots come Page Content per impostazione predefinita e non amplia il comportamento di compatibilità degli Shared Slot

Confine di portabilità

  • L'esportazione/importazione dei siti e la clonazione trasferiscono ancora gli handle public_shell a livello di pagina come configurazione della pagina
  • Nella V1 le definizioni di Page Layout e di Page Layout Slot a livello di installazione non sono incluse nell'esportazione/importazione dei siti
  • Se una pagina trasferita usa un handle di layout personalizzato, l'installazione di destinazione dovrebbe avere un handle di Page Layout corrispondente per ottenere il comportamento previsto
  • Se sull'installazione di destinazione non esiste un layout corrispondente, il rendering ripiega in sicurezza