Concetti fondamentali

WebBlocks CMS utilizza un modello di contenuto relazionale esplicito, costruito attorno a pagine, layout, slot e blocchi.

La struttura di base è:

Page -> Layout -> Slots -> Blocks

• Una pagina possiede il routing, il contesto di sito, lo stato del flusso di lavoro e la scelta del layout.
• Una pagina può possedere anche righe relazionali di Page Assets con riferimenti a file CSS e JS con ambito di pagina.
• Un layout definisce le regioni strutturali disponibili.
• Gli slot sono aree di posizionamento denominate all'interno del layout, come header, main, sidebar e footer.
• I blocchi sono le effettive unità di contenuto collocate negli slot e, quando supportato, annidate sotto altri blocchi.

Le pagine non memorizzano JSON libero da page builder. Contenuti e relazioni sono mantenuti in tabelle relazionali, così la struttura resta esplicita e verificabile.

• Page Assets è una funzionalità core del CMS per i riferimenti a file CSS e JS con ambito di pagina.
• Page Assets è memorizzato in modo relazionale in page_assets, non all'interno del JSON di pages.settings.
• La V1 accetta solo percorsi locali dell'installazione sotto /site/....
• URL esterni, CSS inline, JS inline, query string, frammenti, traversal ed estensioni non corrispondenti vengono rifiutati.
• Attualmente il CSS viene reso solo nell'head del documento pubblico.
• Attualmente il JS viene reso solo nell'head del documento pubblico con defer.
• Gli asset pubblici di proprietà del CMS risiedono sotto public/cms/.
• public/storage è il symlink allo storage pubblico di Laravel per storage/app/public ed è separato dagli asset di override di sito o di pagina.
• I percorsi pubblici canonici degli asset sono public/site/{site_handle}/css/site.css, public/site/{site_handle}/js/site.js, public/site/{site_handle}/pages/{page_slug}/page.css e public/site/{site_handle}/pages/{page_slug}/page.js.
• Page Assets viene reso solo per la pagina pubblica proprietaria ed è escluso dai layout di amministrazione e dalle pagine non correlate.
• Revisioni di pagina, duplicazione, spostamento ed esportazione o importazione del sito trattano Page Assets come configurazione di proprietà della pagina.
• L'importazione JSON di una singola pagina può anche creare righe in page_assets quando il payload usa percorsi locali /site/... validi che superano le regole di validazione esistenti per i Page Assets.
• L'indicizzazione della ricerca non tratta i percorsi dei Page Assets come contenuto del corpo della pagina.

• Una pagina appartiene esattamente a un sito alla volta.
• Il normale form Edit Page mantiene Site in sola lettura per le pagine esistenti.
• La duplicazione di una pagina crea un nuovo record di pagina nello stesso sito o in un altro sito accessibile.
• Gli spostamenti di pagina tra siti usano un flusso di lavoro dedicato Move to another site anziché una modifica di campo inline.
• La duplicazione delle pagine usa un flusso di lavoro dedicato Duplicate page anziché appoggiarsi al normale form di pagina.
• Lo spostamento viene eseguito come transazione controllata, così pages.site_id e page_translations.site_id restano validi rispetto alla chiave esterna composta (page_id, site_id).
• La duplicazione avvia sempre la nuova pagina come bozza e copia lo stato dei contenuti senza copiare la cronologia delle revisioni della pagina di origine.
• Lo spostamento conserva l'id della pagina, le traduzioni, gli slot, i blocchi di proprietà della pagina, le traduzioni dei blocchi, l'ordine, lo stato del flusso di lavoro e la cronologia delle revisioni.
• La duplicazione conserva layout, traduzioni, slot, blocchi di proprietà della pagina, relazioni tra blocchi annidati, traduzioni dei blocchi e riferimenti compatibili agli Shared Slot, ma crea un nuovo id di pagina.
• I conflitti di percorso sul sito di destinazione sono errori di validazione bloccanti nella versione attuale.
• I riferimenti agli Shared Slot devono poter essere rimappati su Shared Slot compatibili con lo stesso handle nel sito di destinazione, altrimenti lo spostamento viene bloccato.
• La duplicazione nello stesso sito conserva i riferimenti agli Shared Slot esistenti.
• La duplicazione tra siti rimappa solo gli Shared Slot compatibili con lo stesso handle nel sito di destinazione.
• Quando una duplicazione tra siti non riesce a rimappare alcuni slot basati su Shared Slot, il comportamento predefinito resta il blocco della duplicazione.
• Il flusso di lavoro di duplicazione può ora disattivare esplicitamente solo quegli slot incompatibili della pagina duplicata, anziché salvare un riferimento a uno Shared Slot di un altro sito non valido.
• Questa alternativa opzionale scrive lo slot della pagina duplicata come disabled, azzera shared_slot_id, lascia invariata la pagina di origine e in questa versione non copia gli alberi di blocchi degli Shared Slot nella pagina duplicata.
• Gli strumenti di portabilità a livello di sito, come Export / Import e Site Clone, restano separati dagli spostamenti e dalla duplicazione delle pagine.
• Admin -> Pages -> Import Page è un flusso di lavoro di portabilità con ambito di pagina. Crea una nuova pagina da un payload JSON documentato webblocks.cms.page.v1 ed è intenzionalmente separato dall'Export / Import a livello di sito.
• L'importazione V1 di una singola pagina crea sempre una nuova pagina e la importa sempre come bozza.
• L'importazione V1 di una singola pagina non importa la cronologia delle revisioni della pagina di origine.
• Nell'importazione di una singola pagina, gli slot di pagina basati su Shared Slot devono fare riferimento a uno Shared Slot compatibile del sito di destinazione tramite handle stabile. Nella V1 l'importatore non crea automaticamente Shared Slot.

• L'identità di prodotto di WebBlocks CMS è fissa nella shell di amministrazione e proviene da App\Support\WebBlocks.
• Project Identity è il contesto di amministrazione a livello di installazione configurato in Admin -> System -> Settings.
• Project Identity comprende attualmente Project Name e Project Tagline.
• Project Identity viene usato solo per il contesto della topbar di amministrazione e per i titoli del browser nell'area di amministrazione.
• Project Identity non modifica il brand fisso della sidebar di WebBlocks CMS, il footer di versione della sidebar, i metadati pubblici del sito, la favicon pubblica, l'ambito della ricerca pubblica o i valori SEO delle traduzioni di pagina.
• I record di sito possiedono l'identità e i metadati rivolti al pubblico.
• sites.name resta il nome interno del record nell'amministrazione.
• display_name è l'override opzionale del nome pubblico del sito.
• tagline è testo pubblico opzionale per il sito.
• seo_title, seo_description e seo_keywords sono metadati di fallback a livello di sito.
• favicon_media_id e social_image_media_id sono riferimenti media opzionali a livello di sito per l'output dell'head pubblico.
• site_variables sono valori di testo semplice riutilizzabili e opzionali a livello di sito, per la sostituzione controllata di token pubblici.
• Anche le righe di traduzione di pagina possiedono campi di override SEO localizzati come seo_title, seo_description, seo_keywords, og_title, og_description e og_image_media_id.
• Questo mantiene i metadati pubblici della pagina dipendenti dalla lingua e fuori dalle impostazioni JSON condivise della pagina.

• Media è il nome canonico dei file caricati condivisi nell'intero runtime attivo del CMS.
• I nomi tecnici attivi usano ora Media, media_id, media, media_folders e block_media nel codice di runtime corrente, nelle richieste, nelle revisioni e nei pacchetti di trasferimento del sito.
• I nomi legacy Asset restano solo per i wrapper di compatibilità, le migrazioni storiche e la normalizzazione di payload o archivi più vecchi.
• Admin -> Media mantiene il titolo principale dell'elenco Media e il titolo della card del listato Media Library.
• Nell'elenco Media, sia il link del titolo sia l'icona della matita aprono Edit Media: {title} e portano con sé un URL di ritorno sicuro all'elenco filtrato corrente.
• L'icona dell'occhio resta l'azione di anteprima ingrandita in modale dall'elenco.
• La rotta di dettaglio /webadmin/media/{id} reindirizza a /webadmin/media/{id}/edit, così i link di dettaglio dei media portano alla schermata di modifica canonica.
• Edit Media unisce anteprima, dettagli del file, metadati, organizzazione, utilizzo e gestione della zona di pericolo in un'unica schermata.
• Copy public URL si trova ora nell'area File Details della schermata di modifica anziché nella colonna delle azioni dell'elenco.
• L'eliminazione segue il modello standard modale di amministrazione più Danger Zone anziché il markup di conferma del browser.

• Le Site Variables sono memorizzate in modo relazionale in site_variables.
• Sono record ordinati con ambito di sito, dotati di chiave, etichetta, valore, stato di abilitazione e ordinamento.
• La sintassi dei token pubblici supportata è esattamente {{ site.variable_key }}, con spazi interni opzionali.
• Le chiavi vengono normalizzate in snake_case minuscolo e devono corrispondere al pattern conservativo ^[a-z][a-z0-9_]*$.
• Token sconosciuti, variabili disabilitate, chiavi non valide e token non di sito restano invariati.
• La sostituzione è solo testuale. Non è un motore di template generico.
• Non sono supportati condizionali, cicli, chiamate a funzioni, accesso a env, accesso alla config, esecuzione di PHP, variabili annidate o espressioni arbitrarie.
• La sostituzione avviene solo durante il rendering pubblico condiviso e l'indicizzazione della ricerca pubblica.
• I form e le anteprime di amministrazione conservano il testo del token così come è memorizzato.
• I valori delle variabili sono trattati come testo semplice. Nei contesti pubblici che supportano HTML vengono inseriti come testo con escape, non come markup eseguibile.

La modifica avviene attraverso gli slot.

Flusso tipico:

1. Create una pagina.
2. Assegnate un layout.
3. Modificate gli slot del layout.
4. Aggiungete e ordinate i blocchi all'interno di quegli slot.

I blocchi possono avere relazioni padre-figlio, il che consente strutture di contenuto raggruppate senza ridurre il modello a blob opachi.

I blocchi sono le unità editoriali riutilizzabili del CMS.

• I dati condivisi contengono struttura, posizionamento, asset e impostazioni operative.
• I dati tradotti contengono il testo rivolto all'utente per ciascuna lingua.
• I contenuti rivolti all'utente non sono memorizzati in blob JSON arbitrari.

I blocchi di navigazione di sistema seguono la stessa regola relazionale. Navbar mantiene l'handle persistito sticky-navbar per compatibilità, ma ora si comporta come un blocco contenitore primitivo: rende solo nav.wb-navbar più i blocchi figli annidati. Da solo non rende il markup del brand, i link di menu, le azioni di header o un contenitore forzato.

La composizione della Navbar è relazionale anziché guidata da JSON:

• Navbar possiede solo la semantica del wrapper e un'impostazione condivisa Position.
• Container possiede il vincolo di larghezza. I container legacy continuano per compatibilità a usare per impostazione predefinita il flusso impilato, ma Flow = None rende Container neutro rispetto al layout, così i blocchi di layout figli controllano la composizione.
• Cluster è la primitiva di layout orizzontale o raggruppato. Le sue impostazioni controllano larghezza, giustificazione, allineamento sull'asse trasversale, mandata a capo e spaziatura.
• Stack resta la primitiva di flusso verticale.
• Navbar Brand possiede il logo e il testo del brand.
• Navbar Navigation possiede la selezione del menu e rende i navigation_items del sito usando le classi navbar di WebBlocks UI. Sugli schermi stretti rende anche un pulsante burger accessibile che apre lo stesso menu tramite il comportamento dropdown di WebBlocks UI, lasciando brand e azioni di header nella riga principale della navbar.
• Header Actions, Search Form, Container e altri blocchi compatibili possono essere collocati all'interno di Navbar come figli quando necessario.
• Navbar Brand e Navbar Navigation devono trovarsi da qualche parte all'interno dell'albero degli antenati di Navbar, ma non devono necessariamente essere figli diretti del blocco radice Navbar.
• Navbar Brand supporta l'uso con solo logo quando esiste un'immagine di logo. Quando il testo del titolo visibile è vuoto, un'etichetta accessibile esplicita o l'etichetta risolta del sito forniscono il nome di riserva sicuro.

Composizione consigliata:

• Navbar
• Container (Flow: None)
• Cluster (Width: Full, Justify: Between, Align: Center, Wrap: Nowrap)
• Navbar Brand
• Cluster (Justify: End, Align: Center, Wrap: Nowrap)
• Navbar Navigation
• Header Actions

Usate Container per la larghezza, Cluster per la distribuzione orizzontale e Stack per il flusso verticale. Navbar resta solo il wrapper nav e non aggiunge da solo helper di layout specifici del CMS.

Questo mantiene la composizione dell'header esplicita, riutilizzabile e allineata a WebBlocks UI, invece di duplicare una superficie di design della navbar riservata al CMS.

Questo mantiene chiara la proprietà dei contenuti in multisito, localizzazione, revisioni e rendering pubblico.

La ricerca V1 è infrastruttura pubblica derivata, non logica di sito web del livello di progetto.

• La ricerca indicizza solo le pagine pubbliche pubblicate.
• Le righe di ricerca hanno ambito per sito e lingua.
• La ricerca usa le traduzioni di pagina come fonte di verità per il titolo e i metadati dell'URL pubblico.
• Il contenuto di ricerca è costruito dai blocchi pubblicati di proprietà della pagina più i blocchi compatibili degli Shared Slot risolti nel contesto della pagina che li utilizza.
• Le pagine di origine degli Shared Slot nascoste sono escluse dalla risoluzione delle rotte pubbliche e dai risultati di ricerca autonomi.
• La prima versione memorizza le righe derivate nella tabella di database public_search_index e usa un matching SQL conservativo anziché un servizio di ricerca esterno.
• Le righe di ricerca sono dati di runtime derivati e possono essere ricostruite in sicurezza dai contenuti del CMS.

La struttura della pagina pubblica è controllata a livello di pagina e di slot.

• Page Layout è il nome visibile nell'amministrazione per la configurazione del guscio esterno a livello di pagina.
• I Page Layout sono ora record gestiti a livello di installazione in Admin -> System -> Page Layouts.
• Il campo di compatibilità memorizzato resta public_shell in questa fase, così i dati e gli handle di pagina esistenti restano validi.
• default è il guscio pubblico standard.
• docs è il guscio orientato alla documentazione per layout con regioni di intestazione, barra laterale e contenuto principale.
• I Default Layout e Docs Layout integrati sono layout di sistema precaricati con gli handle stabili default e docs.
• Le pagine memorizzano l'handle del Page Layout selezionato, non una modalità di guscio risolta separata.
• Page Layout ora possiede token pubblici body_class opzionali e validati.
• I Page Layout Slot sono record relazionali a livello di installazione collegati a un Page Layout che definiscono l'ordine degli slot e i metadati del wrapper.
• Gli Slot Type sono il catalogo riutilizzabile per l'assegnazione dei Page Layout Slot.
• Il rendering a runtime risolve l'handle memorizzato in un record Page Layout quando disponibile, quindi risolve le classi del body e i wrapper degli slot a partire dai suoi Page Layout Slot gestiti.
• Body Class è pensato per il CSS specifico del layout sul <body> pubblico, mentre gli id e le classi dei wrapper dei Page Layout Slot forniscono agganci CSS a livello di regione all'interno di quel layout.
• Il comportamento sticky della Navbar pubblica deriva dalla primitiva wb-navbar inclusa. Quando uno slot di intestazione pubblico predefinito contiene solo un blocco Navbar, il CMS promuove il wrapper dello slot alla radice nav.wb-navbar affinché il comportamento sticky non sia vincolato da un ulteriore wrapper di intestazione.
• Edit Page confronta i Layout Slot gestiti del Page Layout selezionato con i Page Slot attuali della pagina.
• I Layout Slot mancanti possono essere aggiunti esplicitamente tramite Add Missing Layout Slots.
• I Page Slot in eccesso vengono conservati per sicurezza e vengono segnalati anziché eliminati.
• Le nuove pagine utilizzano i Page Layout Slot gestiti attivi del Page Layout selezionato prima di ricadere sugli array di slot legacy.
• Cambiare il Page Layout in un salvataggio normale non modifica automaticamente i Page Slot esistenti.
• I Page Layout personalizzati di V1 possono usare handle personalizzati, ma riutilizzano comunque in modo conservativo il comportamento di guscio default o docs esistente per compatibilità.
• Il nome dello slot determina il ruolo semantico del wrapper pubblico per quella regione.
• I wrapper degli slot vengono risolti automaticamente dai Page Layout Slot gestiti quando disponibili, con definizioni di ripiego legacy per i layout integrati. Gli slot sconosciuti usano il wrapper div predefinito sicuro.
• L'HTML di layout avanzato e attendibile esiste solo per il markup strutturale adiacente al wrapper. Non è una superficie di scripting generica e non deve essere usato per gli script.
• Gli slot di intestazione sono neutrali rispetto al layout per impostazione predefinita e non impongono wb-stack attorno ai loro alberi di blocchi.
• Gli slot principali possono comunque gestire il ritmo impilato tramite il loro partial di guscio quando tale presentazione è intenzionale.
• La spaziatura tra intestazione e contenuto principale appartiene al wrapper del guscio pubblico, non a Navbar né ad altri singoli blocchi di intestazione. I wrapper di intestazione e principale del guscio predefinito gestiscono quel ritmo, così il primo blocco di contenuto non ha bisogno di margini superiori improvvisati.
• Il comportamento sticky della navbar deve restare di proprietà del contratto .wb-navbar incluso in WebBlocks UI. Il page layout e i wrapper degli slot di intestazione gestiscono la struttura a livello di pagina, ma il CMS non deve iniettare una classe sticky di navbar parallela.
• I blocchi renderizzano il contenuto dentro quei wrapper di slot e non devono possedere il guscio esterno della pagina.
• La validazione del Page Layout consente frammenti di wrapper attendibili per colmare lacune strutturali, ma rifiuta script, attributi di evento, URL javascript: e contenuti iframe, object ed embed.

Per le pagine in stile documentazione, usate il page layout invece di spostare la responsabilità del layout sui singoli blocchi di contenuto. La ricetta abituale è Page Layout = Docs Layout con gli slot Header, Sidebar e Main, così il guscio può mapparli automaticamente sui wrapper di navbar, barra laterale e contenuto principale della documentazione.

In V1, Page Layout possiede la scelta del guscio pubblico esterno, i nomi degli slot possiedono la semantica dei wrapper di regione e i blocchi possiedono il contenuto all'interno di quei wrapper.

• I metadati pubblici vengono risolti a partire dal sito corrente e dal contesto di traduzione della pagina corrente, non da Project Identity né dalle impostazioni legacy modificabili di nome o slogan dell'applicazione.
• I titoli pubblici delle pagine sono per impostazione predefinita Site Label · Page Label.
• La precedenza dell'etichetta del sito è: display_name del sito, seo_title del sito, name del sito e infine un valore di ripiego sicuro del CMS.
• La precedenza dell'etichetta della pagina è: seo_title della traduzione della pagina, quindi il titolo della traduzione della pagina.
• La precedenza della descrizione è: seo_description della traduzione della pagina, seo_description del sito, altrimenti nessun tag di descrizione.
• La precedenza delle parole chiave è: seo_keywords della traduzione della pagina, seo_keywords del sito, altrimenti nessun tag di parole chiave.
• La precedenza del titolo Open Graph è: og_title della traduzione della pagina, altrimenti lo stesso schema di titolo pubblico con il sito in primo piano.
• La precedenza della descrizione Open Graph è: og_description della traduzione della pagina, seo_description della traduzione della pagina, seo_description del sito.
• La precedenza dell'immagine Open Graph è: og_image_media_id della traduzione della pagina, social_image_media_id del sito, altrimenti nessun tag og:image.
• Il media della favicon del sito è invariato e in questa fase resta ancora solo a livello di sito.
• I metadati multisito restano consapevoli dell'host attraverso il sito pubblico risolto; il sito primario non viene usato ciecamente quando un altro sito corrisponde all'host corrente.

• La ricerca pubblica resta limitata al sito e alla lingua (locale) risolti.
• Il testo della finestra modale di ricerca può includere l'etichetta del sito risolta, così gli utenti vedono in quale sito si sta cercando.
• Il testo della ricerca pubblica usa Site Identity, non Project Identity.

Gli Shared Slot sono un livello di proprietà del contenuto degli slot che si colloca sotto il modello di page layout esistente.

• Il page layout continua a determinare quali slot sono disponibili.
• Il guscio di pagina più il nome dello slot continuano a determinare i wrapper pubblici di ciascuno slot.
• L'origine di ogni slot di pagina può essere page, shared_slot o disabled.
• page significa che lo slot usa blocchi di proprietà diretta della pagina, che resta il comportamento attuale.
• shared_slot significa che lo slot fa riferimento a un albero di blocchi Shared Slot riutilizzabile e limitato al sito, renderizzato dinamicamente a runtime pubblico.
• disabled significa che il wrapper dello slot esiste ancora, ma al suo interno non viene renderizzato alcun blocco.
• Gli Shared Slot sono alberi di blocchi di slot riutilizzabili e limitati al sito, non modelli basati su copie.
• I riferimenti agli Shared Slot sono validi solo all'interno dello stesso sito. Le operazioni di pagina tra siti devono essere rimappate su uno Shared Slot compatibile del sito di destinazione oppure ricadere su un risultato sicuro di blocco o disattivazione, a seconda dell'operazione e della scelta esplicita dell'utente.
• Gli Shared Slot non possiedono i gusci di pagina né i wrapper degli slot. Il guscio di pagina possiede ancora il guscio esterno e lo slot di pagina consumatore possiede ancora il wrapper per header, main, sidebar o altre regioni di slot.
• Uno Shared Slot valido contribuisce solo con l'albero di blocchi renderizzato all'interno di quel wrapper di slot di pagina esistente.
• Il rendering pubblico degli Shared Slot è conservativo:
• I riferimenti a shared slot di un altro sito non renderizzano nulla.
• Le schermate di amministrazione degli Shared Slot descrivono il vincolo opzionale SharedSlot.public_shell come Page Layout, ma il nome del campo memorizzato resta public_shell per retrocompatibilità in questa release.
• Se SharedSlot.public_shell è impostato, deve corrispondere esattamente all'handle del page layout consumatore.
• Se SharedSlot.slot_name è impostato, deve corrispondere al nome dello slot di pagina consumatore.
• Valori nulli o vuoti di public_shell e slot_name agiscono come corrispondenze generiche.
• Un handle di Page Layout personalizzato che mappa su shell_type = docs non corrisponde automaticamente a uno Shared Slot vincolato a docs in V1.

L'ambito attuale comprende ora le fondamenta, il rendering pubblico, la gestione amministrativa limitata al sito, l'assegnazione dell'origine degli slot di pagina e il supporto alla portabilità tra siti per gli Shared Slot.

• Gli Shared Slot hanno un proprio elenco di amministrazione e propri form di metadati nell'area dei contenuti di sito dell'amministrazione.
• Gli alberi di blocchi degli Shared Slot si modificano tramite un editor di blocchi dedicato agli Shared Slot che riutilizza l'attuale modello di authoring dei blocchi invece di copiare il contenuto negli slot di pagina consumatori.
• I blocchi degli Shared Slot restano record blocks reali collegati tramite shared_slot_blocks, con il testo tradotto che resta nelle tabelle di traduzione esistenti.
• L'eliminazione di uno Shared Slot è bloccata finché uno slot di pagina vi fa ancora riferimento.
• L'editor di pagina espone ora un selettore di origine per slot con tre modalità supportate:
• Page Content: page_slots.source_type = page e shared_slot_id = null.
• Shared Slot: page_slots.source_type = shared_slot e shared_slot_id punta a uno Shared Slot attivo e compatibile dello stesso sito.
• Disabled: page_slots.source_type = disabled e shared_slot_id = null.
• Cambiare l'origine di uno slot non elimina né scollega l'albero di blocchi di proprietà della pagina per quello slot. Se un editor passa uno slot a shared_slot o disabled, i blocchi di proprietà della pagina restano collegati, così tornando a Page Content si ripristina il contenuto specifico della pagina precedente.
• L'aggiunta dei Layout Slot mancanti segue lo stesso principio di sicurezza: crea solo nuovi Page Slot e non altera gli slot supportati da Shared Slot, gli slot Disabled né gli alberi di blocchi di proprietà della pagina.
• L'editor di pagina filtra le scelte di Shared Slot in modo conservativo. Compaiono solo gli Shared Slot attivi dello stesso sito e i vincoli opzionali public_shell e slot_name dello Shared Slot devono corrispondere al guscio e al nome dello slot della pagina consumatrice.
• I form di amministrazione degli Shared Slot etichettano ora quel vincolo opzionale public_shell come Page Layout, così il termine visibile all'utente corrisponde alle schermate dell'editor di pagina e di gestione dei Page Layout.
• L'esportazione/importazione e la clonazione del sito trasferiscono ancora gli handle public_shell a livello di pagina come parte della configurazione della pagina. Le definizioni di Page Layout a livello di installazione restano locali all'installazione in V1, quindi le installazioni di destinazione dovrebbero definire gli handle personalizzati che si aspettano di renderizzare senza ripiego.
• Anche le definizioni di Page Layout Slot a livello di installazione restano locali all'installazione in V1.
• Le protezioni di rendering pubblico a runtime restano attive anche dopo la validazione in scrittura, così le assegnazioni non valide, obsolete, di altri siti, inattive o incompatibili continuano a non renderizzare pubblicamente alcun contenuto condiviso.
• Gli Shared Slot partecipano ora all'esportazione/importazione e alla clonazione del sito. I loro metadati, gli alberi di blocchi delle pagine sorgente nascoste, le traduzioni, l'ordinamento annidato e i riferimenti ai media vengono trasferiti come contenuto di sito di prima classe. Gli slot di pagina consumatori mantengono i riferimenti shared_slot tramite l'handle dello Shared Slot durante l'esportazione e vengono rimappati sugli Shared Slot del sito di destinazione durante importazione e clonazione.
• Le pagine sorgente nascoste degli Shared Slot restano interne. Sono escluse dai normali payload di esportazione delle pagine, dagli elenchi di pagine ordinari e dal routing pubblico, anche se i loro record di blocchi continuano a sostenere l'editor degli Shared Slot e i flussi di portabilità.
• Gli Shared Slot hanno ora una propria cronologia delle revisioni e un proprio flusso di ripristino, intenzionalmente separato dalle revisioni di pagina.
• Le revisioni degli Shared Slot catturano i metadati dello Shared Slot più l'albero di blocchi riutilizzabile dello Shared Slot dietro la pagina sorgente interna nascosta.
• Il ripristino di una revisione di Shared Slot ripristina lo Shared Slot sul posto. L'id dello Shared Slot resta stabile, i riferimenti page_slots.shared_slot_id esistenti restano intatti e il contenuto ripristinato ha effetto immediato su ogni pagina che fa riferimento a quello Shared Slot.
• Le revisioni degli Shared Slot non considerano le revisioni di pagina autorevoli per il contenuto degli Shared Slot, e le revisioni di pagina non pretendono di catturare gli alberi di blocchi degli Shared Slot.

La pubblicazione del flusso di lavoro di pagina e la pubblicazione dei blocchi sono separate per impostazione predefinita. Pubblicare un record di pagina rende la pagina instradabile quando le sue regole di lingua (locale) e di percorso corrispondono, ma non pubblica silenziosamente i blocchi in bozza o in revisione all'interno di quella pagina. Questo consente a editor e revisori di pubblicare il guscio della pagina trattenendo alcuni blocchi per una revisione successiva.

Quando un utente sceglie esplicitamente di includere i blocchi di proprietà della pagina, WebBlocks CMS pubblica solo i blocchi di proprietà degli slot di pagina non condivisi della pagina. I blocchi figli annidati sotto quegli slot di proprietà della pagina sono inclusi. Gli slot supportati da Shared Slot sono esclusi; i loro alberi di blocchi riutilizzabili devono essere revisionati e pubblicati tramite i flussi di lavoro specifici degli Shared Slot.

La Internal Content API segue la stessa regola. POST /webadmin/api/pages/{page}/publish usa per impostazione predefinita include_page_owned_blocks: false, richiede content.publish ed esclude gli Shared Slot. Gli strumenti di IA o operatore devono attivare include_page_owned_blocks: true solo con l'approvazione esplicita dell'utente.

• Site Promotion opera sul contenuto di proprietà del sito, non sull'intera installazione.
• Può aggiornare campi sicuri di identità del sito, assegnazioni di lingua (locale), variabili di sito, pagine, traduzioni di pagina, slot, blocchi, Shared Slot, navigazione, asset di pagina e, facoltativamente, asset di file del pacchetto.
• Preserva i dati a livello di installazione e di runtime live come utenti, sessioni, backup, cronologia degli aggiornamenti, invii dei moduli di contatto, reportistica sui visitatori, domini, impostazioni di ambiente e segreti.
• Non tratta public_search_index come contenuto portabile. Le righe di ricerca vengono ricostruite dal contenuto promosso dopo l'applicazione.
• È un flusso di lavoro a pacchetti controllato, non una replica grezza del database.

Il core di WebBlocks CMS contiene le funzionalità CMS riutilizzabili.

• Tenete in project/ il codice specifico dell'installazione che deve sopravvivere agli aggiornamenti del CMS.
• Tenete fuori dal core i comandi, le viste, le rotte, la configurazione, gli helper di importazione e i flussi di migrazione specifici del sito quando non sono funzionalità di prodotto riutilizzabili.
• Trattate project/ come il confine di estensione sicuro rispetto agli aggiornamenti per una singola installazione.
• Tenete nel core il comportamento di prodotto riutilizzabile come blocchi, layout, interfaccia di amministrazione, renderer pubblici, workflow, backup/ripristino, esportazione/importazione e il supporto generico del livello di progetto.
• Tenete in project/ gli helper di migrazione/importazione dei siti e gli strumenti di sincronizzazione dei contenuti specifici dell'installazione.
• I ponti di migrazione rapida dei siti web possono vivere in project/ quando sono intenzionalmente temporanei e specifici di un sito web. L'importatore della documentazione rimanente di WebBlocks UI ne è un esempio: memorizza i frammenti <main> della documentazione scaricata come HTML attendibile in forma di payload di progetto, senza insegnare al core del CMS nulla su quel sito web.
• Un ponte di questo tipo dovrebbe preservare il contenuto curato esistente del CMS, mantenere il comportamento del guscio o della navigazione di proprietà del CMS e rendere esplicito il confine temporaneo dell'HTML attendibile, così da lasciare possibile una successiva rifinitura in blocchi di prima classe.
• I pacchetti di rilascio del core non includono contenuti di project/.

Consultate ../DEVELOPMENT.md per il flusso completo di sviluppo e rilascio.