Operazioni

WebBlocks CMS include strumenti operativi a livello di installazione per aggiornamenti, backup e pacchetti di trasferimento dei siti.

Settings si trova anch'esso nella navigazione System dell'amministrazione perché controlla l'identità di progetto, la lingua, il fuso orario, la privacy, la versione e le impostazioni di ambiente a livello di installazione.

Admin -> System -> Block Types funge anche da schermata di ispezione del catalogo a livello di installazione. Il suo filtro Support riguarda i metadati di capacità e di origine dei contenuti dei blocchi, mentre il filtro Usage riguarda i conteggi d'uso reali ricavati dalla tabella blocks, così che gli amministratori possano verificare quali righe di tipi di blocco sono usate e quali no.

Admin -> System -> Visitor Reports fornisce report sul traffico rispettosi della privacy accanto alle impostazioni di sistema a livello di installazione.

Maintenance resta il gruppo di strumenti operativi per:

• Search Rebuild
• Backups
• Export / Import
• Update

Visitor Reports è un report operativo rispettoso della privacy sull'attività delle pagine pubbliche. Le visualizzazioni anonime delle pagine possono essere conteggiate senza identificatori basati sul consenso. Il report memorizza inoltre informazioni solo aggregate su referrer, campagne, dispositivi e bot:

• i referrer sono normalizzati a host/dominio più il tipo direct, internal o external; gli URL completi dei referrer non vengono memorizzati né mostrati
• i referrer vuoti sono raggruppati come Direct / Unknown
• sorgente, mezzo e campagna UTM sono memorizzati solo come valori normalizzati; la query string completa non viene memorizzata
• le stringhe user-agent vengono ridotte al momento della richiesta a una categoria di dispositivo (desktop, mobile, tablet, bot o unknown) più famiglie approssimative di browser/sistema operativo, ove disponibili; le stringhe user-agent complete non vengono memorizzate
• i pattern user-agent noti di crawler e bot vengono conteggiati come visualizzazioni di pagina da bot e restano visibili nel report anziché essere rimossi silenziosamente

Visitatori unici, sessioni, pagine di ingresso e media delle pagine per sessione richiedono un tracciamento di sessione basato sul consenso. Quando un filtro per data/sito/lingua/traffico contiene visualizzazioni di pagina ma nessun identificatore di sessione o visitatore utilizzabile, l'interfaccia mostra Not tracked anziché 0. Le righe più vecchie che non possono essere completate in sicurezza restano Unknown, Direct / Unknown o Not tracked a seconda dei campi aggregati presenti.

L'autorizzazione con ambito di sito continua ad applicarsi: i super admin possono vedere tutti i siti, mentre gli amministratori di sito e gli editor possono vedere solo i dati dei siti assegnati. Il filtro dei siti è limitato ai siti accessibili all'utente.

System Updates confronta la versione del codice CMS in esecuzione con il servizio di aggiornamento configurato.

La schermata di aggiornamento può segnalare stati come:

• aggiornamento disponibile
• aggiornato
• versione locale/sorgente più recente dell'ultima release pubblicata
• aggiornamento incompatibile disponibile
• nessuna release trovata
• server di aggiornamento non disponibile
• risposta non valida o non supportata

Il flusso di aggiornamento in-app scarica il pacchetto della release, applica le regole dei percorsi protetti, esegue le migrazioni di aggiornamento necessarie, svuota le cache, verifica la versione del codice WebBlocks CMS applicata rispetto alla release di destinazione, registra l'esecuzione dell'aggiornamento e salva la versione installata.

La disponibilità di un aggiornamento si basa sul fatto che l'ultima release pubblicata sia più recente della versione del codice CMS in esecuzione. Le esecuzioni di aggiornamento fallite in passato e i valori obsoleti della versione installata memorizzata restano consultabili tramite il modale dell'ultima esecuzione, il report di supporto, la CLI delle esecuzioni conservate o Update Readiness, ma da soli non rendono azionabile un'installazione corrente.

La schermata mostra per impostazione predefinita due card: prima Install Update e poi Update Details. Install Update è l'unica area di azione principale. Quando è disponibile un aggiornamento compatibile, mostra il percorso dalla versione corrente all'ultima, lo stato di compatibilità, la call to action di installazione e una fisarmonica Package Safety Details chiusa. Quando non è disponibile alcun aggiornamento, mostra un messaggio discreto di installazione aggiornata o non disponibile e omette i dettagli di sicurezza del pacchetto.

Update Details contiene righe a fisarmonica di WebBlocks UI per Release Notes, Update Readiness e Last Update Run. Update Readiness descrive l'installazione corrente e i controlli del servizio di aggiornamento; non è il contenuto delle note di rilascio della versione di destinazione. Last Update Run mostra nella schermata principale solo il riepilogo dell'esecuzione rilevante più recente, con i dettagli disponibili in un modale. I super admin possono scaricare un report di supporto dalla stessa card per i flussi di assistenza su hosting condiviso; il report evita token, segreti, percorsi locali assoluti e stack trace grezzi, includendo comunque versione corrente/ultima, prontezza, dettagli dell'ultima esecuzione e riepiloghi delle esecuzioni conservate.

Update History non viene più mostrata come tabella nella schermata principale e l'eliminazione delle righe non fa parte dell'interfaccia di amministrazione. I record delle esecuzioni di aggiornamento vengono ripuliti automaticamente, conservando per impostazione predefinita le ultime cinque esecuzioni. L'ultima esecuzione fallita viene conservata finché non esiste un'esecuzione riuscita più recente. Gli operatori con accesso al terminale possono ispezionare i record conservati con php artisan webblocks:updates:runs, php artisan webblocks:updates:runs --last o php artisan webblocks:updates:runs --failed, e possono eseguire una pulizia controllata con php artisan webblocks:updates:prune-runs --keep=5.

Il client di aggiornamento supporta metadati strutturati provenienti dal servizio di aggiornamento, tra cui titolo, riepilogo, novità principali, correzioni, note di compatibilità, note di migrazione, note sugli asset, note per l'operatore e note tecniche. Questi valori vengono resi come testo semplice con escape in gruppi orientati all'operatore all'interno della fisarmonica Release Notes. Le release più vecchie che forniscono solo release_notes mostrano comunque tali note in modo corretto, mentre le release senza note mostrano No release notes were provided for this release. I controlli di prontezza, la versione installata memorizzata e i valori di basso livello del server di aggiornamento restano in Update Readiness.

La sincronizzazione del catalogo core non fa più parte della normale catena di applicazione di System Update. I pacchetti di release applicano codice, asset, migrazioni di aggiornamento necessarie, svuotamento delle cache, verifica della versione dopo l'applicazione, cronologia delle esecuzioni e persistenza della versione installata; la riparazione estesa del catalogo è un flusso di manutenzione esplicito.

Per la manutenzione manuale o il ripristino su un'installazione esistente, amministratori e sviluppatori possono anche eseguire:

webblocks:catalog-repair supporta --block-types, --slot-types, --page-layouts, --icons e --all. Riporta le righe create, aggiornate, invariate e saltate, preserva le righe di catalogo personalizzate specifiche dell'installazione e può essere eseguito ripetutamente. block-types:sync-core resta un comando di compatibilità di livello più basso per il catalogo dei tipi di blocco.

I pacchetti di release pubblicati sono pacchetti di prodotto core. Distribuiscono codice sorgente CMS riutilizzabile, asset, migrazioni, view, rotte, configurazione, documentazione e test, ma non distribuiscono contenuti del livello di progetto specifici dell'installazione provenienti da project/.

La pubblicazione di release/aggiornamenti del CMS è un flusso di lavoro nativo/locale del manutentore:

release:prepare costruisce localmente lo ZIP con radice di pacchetto, il checksum e il payload per il publisher. release:publish-update invia pacchetto e metadati all'endpoint di pubblicazione predefinito di proprietà del pacchetto https://publisher.webblocksui.com/api/updates/publish, quindi verifica gli ultimi metadati del server di aggiornamento per webblocks-cms sul canale stable. I siti CMS installati non configurano chiavi di ambiente per Publisher/server di aggiornamento, prodotto o canale nei normali file .env; il codice di prodotto del CMS possiede il server di release predefinito, la chiave di prodotto, il canale stable, il percorso dell'ultima versione e il percorso di pubblicazione tramite ReleaseDefaults. Di norma per pubblicare serve solo WEBBLOCKS_PUBLISHER_TOKEN. Le esecuzioni con configurazione in cache aggiornano solo quel token dal .env del progetto e la diagnostica riporta solo se è configurato o meno. Il vecchio ponte updates.webblocksui.com è solo storico e non deve essere usato come percorso di configurazione attivo. I commit e i tag Git sono soltanto passaggi della cronologia del codice sorgente. GitHub Actions, le release di GitHub, gli URL degli asset di GitHub, l'API di GitHub e la CLI gh non fanno parte della pubblicazione degli aggiornamenti del CMS, e i workflow .github sono volutamente assenti.

Le copie di lavoro del CMS installate sono consumatrici di aggiornamenti. Possono recuperare la cronologia del codice sorgente quando serve, ma non devono effettuare push upstream né pubblicare aggiornamenti del CMS da un checkout di installazione.

Gli invii del Contact Form vengono salvati prima della consegna della notifica. Lo stato della notifica email riflette solo il comportamento della notifica e non modifica lo stato editoriale né la classificazione dello spam. Sent significa che Laravel ha accettato l'invio tramite un trasporto di posta reale configurato senza eccezioni; non garantisce la consegna nella casella di posta. Failed significa che è stato tentato un invio reale che ha generato un errore ripulito. Skipped o Not configured significa che non è stato tentato alcun invio reale perché la notifica era disattivata, non è stato risolto alcun destinatario, il mailer è log, array o null, oppure la configurazione SMTP è incompleta. Lo spam con punteggio viene intenzionalmente memorizzato/messo in quarantena per la revisione dell'amministratore; solo gli invii con il campo di controllo generato compilato o troppo rapidi possono essere scartati prima della memorizzazione, con il redirect generico di successo. Una futura soglia configurabile come CONTACT_SPAM_AUTO_DISCARD_SCORE potrà essere valutata quando esisteranno dati di produzione sufficienti per tararla in sicurezza.

I destinatari delle notifiche del Contact Form vengono risolti in questo ordine:

1. recipient_email del blocco Contact Form
2. Destinatario di contatto predefinito del sito da Site -> Edit -> Contact
3. .env CONTACT_RECIPIENT_EMAIL
4. fallback sicuro MAIL_FROM_ADDRESS

Le tipiche impostazioni SMTP di Laravel nel .env sono:

Dopo aver modificato le impostazioni di posta nel .env su un'installazione di produzione o da pacchetto, svuotate la configurazione in cache quando necessario:

Usate il comando di diagnostica della posta privo di segreti quando un Contact Message mostra un errore di notifica:

Il comando riporta il mailer risolto, l'host, la porta, i campi di schema/cifratura, il nome utente, l'indirizzo mittente, CONTACT_RECIPIENT_EMAIL, lo stato della cache di configurazione e gli eventuali fallback di destinatario del blocco Contact Form o del sito. Non stampa mai MAIL_PASSWORD né valori di token. Il test di invio opzionale riporta solo l'esito positivo o un dettaglio di errore ripulito, così gli operatori possono distinguere configurazione obsoleta, disallineamento di host/porta/cifratura, disallineamento tra username e mittente e credenziali della casella non valide, senza far trapelare segreti nei log del terminale.

Usate Contact Messages come fonte di verità per gli invii memorizzati e per lo stato delle notifiche. I mailer di sviluppo come log, array e null non devono essere considerati email consegnate nei report operativi.

Test operativo di verifica:

1. Pubblicate o visualizzate in anteprima una pagina con il blocco nativo contact_form.
2. Inviate un messaggio di prova.
3. Verificate che il messaggio compaia in /webadmin/contact-messages.
4. Controllate lo stato della notifica e il dettaglio sicuro dell'errore.
5. Eseguite php artisan contact:mail-diagnose --block=ID se la risoluzione del destinatario non è chiara.
6. Eseguite php artisan contact:mail-diagnose --send-test=operator@example.com solo per una verifica controllata di invio SMTP.

WebBlocks UI Manager è un plugin interno/per operatori dedicato a operazioni di rilascio specifiche del prodotto. Non è incluso nei normali pacchetti di runtime del CMS e le installazioni CMS ordinarie non dovrebbero installarlo. Costruite il suo artefatto locale dal repository di manutenzione con:

Caricate lo ZIP generato tramite System -> Plugins come super admin, esaminate il dettaglio del plugin installato e poi abilitatelo esplicitamente. I plugin caricati vengono installati disabilitati per impostazione predefinita. Le installazioni disabilitate o incompatibili restano inerti e lo stato di salute non viene controllato finché sono disabilitate.

Se il plugin dichiara migrazioni, l'abilitazione non implica che la configurazione sia completa. La schermata di dettaglio del plugin mostra Setup required / Plugin migrations pending quando mancano tabelle di proprietà del plugin. Usate l'azione da super admin Run Plugin Migrations nella schermata di dettaglio del plugin per eseguire solo le migrazioni dichiarate da quel plugin installato e solo dal percorso di installazione del plugin. L'azione è idempotente, registra un esito di configurazione nel file di stato di abilitazione del plugin e riporta errori privi di segreti. Le rotte di plugin abilitati visibili prima della configurazione devono mostrare indicazioni di setup controllate anziché errori di database grezzi.

Se un'installazione ha eseguito brevemente la v1.32.67 e ha creato tabelle webblocks_ui_manager_*, questa patch non le elimina automaticamente. Anche la disinstallazione manuale del plugin conserva le tabelle di proprietà del plugin. Lasciatele al loro posto a meno che un operatore non abbia confermato che il plugin non serve ed esegua una pulizia manuale separata del database con un backup.

Quando è installato, abilitato e configurato manualmente, il plugin aggiunge /webadmin/plugins/webblocks-ui-manager/releases per i metadati delle release di WebBlocks UI, la validazione in dry-run e la pubblicazione su CDN statico locale. Gli utenti CMS super_admin possono aprire le rotte dei plugin abilitati tramite i permessi di proprietà del plugin dichiarati nel manifest; i ruoli diversi da super admin richiedono concessioni esplicite di permessi del plugin. Se mancano webblocks_ui_manager_releases, webblocks_ui_manager_artifacts o webblocks_ui_manager_publish_runs, la schermata Releases mostra le indicazioni di configurazione necessaria e rimanda al setup del plugin anziché interrogare tabelle inesistenti. Preparate una release con i file dist locali di WebBlocks UI:

Il comando registra i metadati della release, calcola i checksum SHA-256 e prepara i metadati del manifest per la convenzione statica di prima parte public/cdn/webblocks-ui/{version}/.... I file dist attesi sono configurati da webblocks-plugins.webblocks_ui_manager.expected_dist_files e per impostazione predefinita sono webblocks-ui.css, webblocks-icons.css e webblocks-ui.js.

Validate il piano di pubblicazione senza scrivere file:

Applicate la pubblicazione locale dopo che la validazione in dry-run è andata a buon fine:

Il flusso di pubblicazione valida i percorsi di origine, la corrispondenza tra versione e percorso di destinazione, i file dist attesi, i checksum memorizzati, la coerenza del manifest e l'idempotenza prima della scrittura. I file esistenti con checksum corrispondente vengono saltati. I file esistenti con checksum diverso bloccano la pubblicazione. La destinazione è locale/di proprietà del progetto per impostazione predefinita tramite WEBBLOCKS_UI_MANAGER_CDN_BASE_PATH=cdn/webblocks-ui; WEBBLOCKS_UI_MANAGER_CDN_BASE_URL è metadato opzionale di visualizzazione/URL. Il flusso di lavoro non esegue il deploy su un server di produzione esterno, non pubblica metadati sul server di aggiornamento e non modifica gli URL degli asset WebBlocks UI del core CMS.

System -> Plugins segnala separatamente gli stati disabilitato, abilitato, incompatibile, file mancanti ed errore. I plugin disabilitati mostrano uno stato di salute inattivo, non di errore. Un plugin configurato come abilitato ma incompatibile resta inerte: non diventano attivi rotte, comandi, menu, permessi, rotte di impostazioni, widget, asset, dichiarazioni di blocchi o comportamenti di reporting sullo stato di salute del plugin.

La disinstallazione manuale è disponibile solo per i plugin caricati manualmente e dopo che sono stati disabilitati. Rimuove la directory del pacchetto installato di proprietà dello storage e il file di stato di abilitazione, mai file core del CMS, asset pubblici di /cms, file di progetto, file vendor o storage al di fuori della radice dei plugin configurata. Non esegue migrazioni distruttive né elimina tabelle di database di proprietà del plugin.

Il deployment su una CDN di produzione esterna, gli smoke check su CDN ospitate, il comportamento generico di installazione/aggiornamento dei plugin di terze parti, gli installer remoti arbitrari, l'installazione di pacchetti Composer, la pubblicazione su un update server e i flussi marketplace/catalogo restano intenzionalmente rinviati.

Backup / Restore è lo strumento di ripristino a livello di ambiente.

I backup possono includere:

• dump del database
• upload gestiti dal CMS da storage/app/public
• metadati dell'archivio in manifest.json

Il comportamento di ripristino è esplicito:

• possono essere ripristinati solo i backup completati con un archivio valido
• il download dell'archivio, il dettaglio, l'idoneità al ripristino e le azioni di eliminazione risolvono i percorsi attraverso la stessa radice del disco backups e bloccano il traversal, le fughe tramite symlink e i percorsi assoluti fuori da quella radice
• i file di archivio mancanti o illeggibili vengono mostrati come messaggi controllati nell'amministrazione anziché come eccezioni grezze del filesystem
• il ripristino crea prima un backup di sicurezza pre-ripristino
• il ripristino sostituisce il database corrente
• il ripristino sostituisce storage/app/public quando gli upload sono inclusi nell'archivio
• i ripristini MySQL/MariaDB eseguono l'importazione con protezioni temporanee su chiavi esterne e controlli di unicità, così i dump completi validi restano portabili anche quando l'ordine di creazione delle tabelle differisce fra ambienti
• le installazioni esistenti aggiornate tramite System Update eseguono anche, quando necessario, migrazioni di riparazione di proprietà del pacchetto; ciò mantiene allineati contratti di schema come la chiave padre pages(id, site_id) con backup che contengono chiavi esterne di page_translations con ambito di sito

Usate Backup / Restore quando dovete ripristinare l'ambiente dell'installazione, non solo una pagina.

Export / Import è lo strumento di portabilità dei siti.

Usatelo per spostare i contenuti di un sito fra installazioni.

I pacchetti di trasferimento del sito sono memorizzati sul disco del filesystem Laravel denominato site-transfers, che per impostazione predefinita è storage/app/site-transfers. Le nuove installazioni consumer via Composer registrano automaticamente questo disco e webblocks:install prepara la directory di storage, quindi le applicazioni host non devono modificare config/filesystems.php a meno che non vogliano fornire un disco personalizzato.

Le importazioni di sito richiedono che i cataloghi dei tipi di blocco e dei tipi di slot basati su database dell'installazione di destinazione contengano le righe referenziate dal pacchetto. Le nuove installazioni via Composer popolano questi cataloghi durante webblocks:install, la manutenzione esplicita del catalogo può riparare le righe fornite con webblocks:catalog-repair e l'esecutore dell'importazione effettua una sincronizzazione finale idempotente del catalogo core prima della validazione quando un pacchetto referenzia una riga core fornita mancante. Se un pacchetto referenzia un blocco o uno slot personalizzato specifico dell'installazione non presente sulla destinazione, l'errore di amministrazione elenca gli identificatori mancanti esatti.

Il flusso di lavoro di amministrazione ha ora due punti di ingresso correlati:

• Admin -> Sites include un'azione di riga Export per singolo sito che apre una modale per il sito selezionato, mostra il nome e l'handle del sito e può includere i file media prima di creare il pacchetto.
• Admin -> Maintenance -> Export / Import è la schermata operativa combinata per la cronologia e le azioni di trasferimento. Mostra insieme Site Exports e Site Imports, con le azioni Run Export e Run Import nelle intestazioni delle card di elenco pertinenti.
• La schermata di revisione dell'importazione mantiene l'azione sul pacchetto validato subito sotto il riepilogo di stato e manifest, poi mostra i conteggi del pacchetto in una tabella compatta per una lettura più rapida.
• Le nuove installazioni consumer via Composer renderizzano le schermate Export / Import dal namespace delle viste del pacchetto, quindi non richiedono file Blade in resources/views/admin/site-transfers/* nella root.

Relazione fra gli strumenti:

• L'azione Export nella riga di Sites crea un pacchetto per un solo sito selezionato e torna all'elenco dei siti con un messaggio di successo.
• Export / Import gestisce la cronologia dei pacchetti ed è la schermata principale delle operazioni di esportazione o importazione.
• Sites -> Promote applica un pacchetto di esportazione o promozione a un sito di destinazione esistente con dry run, strategia, backup di sicurezza e regole di conservazione.

Export / Import copre contenuti con ambito di sito, come:

• il record del sito e le assegnazioni di lingua (locale)
• le variabili di sito memorizzate in site_variables
• pagine e traduzioni di pagina
• gli asset di pagina memorizzati in page_assets
• slot e blocchi
• gli Shared Slots e i relativi alberi di blocchi
• le impostazioni di Page Layout a livello di pagina, come default e docs (ancora memorizzate internamente su public_shell)
• traduzioni dei blocchi
• elementi di navigazione, inclusi gli slug opzionali delle icone usati dai renderer pubblici di Sidebar Navigation
• file media opzionali
• i file canonici di override pubblico a livello di sito in public/site/{site_handle}/css/site.css e public/site/{site_handle}/js/site.js quando Include media files è attivo e tali file esistono

I Page Assets viaggiano nella portabilità del sito su due livelli:

• le righe di page_assets sono sempre incluse nei payload di esportazione e importazione del sito.
• Quando Include media files è attivo, i file pubblici /site/... referenziati vengono anch'essi inseriti nell'archivio di esportazione e ripristinati in public/site/... durante l'importazione.
• Quando Include media files è disattivato, i metadati degli asset di pagina vengono comunque importati, ma i file fisici referenziati devono già esistere sull'installazione di destinazione.
• Nella versione attuale i file di asset di pagina mancanti vengono segnalati durante l'esportazione e saltati, invece di far fallire l'intera creazione del pacchetto.

Gli asset pubblici di override a livello di sito sono intenzionalmente più ristretti dei Page Assets: vengono inclusi solo css/site.css e js/site.js sotto l'handle del sito di origine, e l'importazione li ripristina sotto l'handle del sito di destinazione finale. Alberi arbitrari public/site/..., asset del core CMS e public/storage non fanno parte di questo percorso.

Gli Shared Slots vengono esportati e importati come contenuti di sito di prima classe:

• Nel pacchetto sono inclusi i metadati degli Shared Slot come handle, nome, compatibilità di slot, compatibilità di shell e stato attivo.
• Gli Shared Slots possono inoltre portare un vincolo opzionale di compatibilità con un Page Layout. Il campo memorizzato resta public_shell per retrocompatibilità, il valore vuoto resta generico e i valori non vuoti richiedono comunque una corrispondenza esatta dell'handle del Page Layout.
• Gli alberi di blocchi degli Shared Slot, l'ordine annidato, le traduzioni e i riferimenti media passano dalla stessa pipeline di packaging di blocchi e media usata per le pagine normali.
• Gli slot di pagina che usano shared_slot esportano un riferimento stabile all'handle dello Shared Slot e vengono rimappati sullo Shared Slot importato del sito di destinazione durante l'importazione.
• I payload di pagina preservano il Page Layout di ciascuna pagina, così le pagine con shell docs mantengono dopo l'importazione assegnazioni compatibili di Shared Slot per la documentazione.
• Le definizioni di Page Layout e di Page Layout Slot a livello di installazione non fanno parte dell'esportazione/importazione di sito nella V1.
• Gli handle public_shell personalizzati delle pagine vengono comunque trasferiti con il payload della pagina, quindi le installazioni di destinazione dovrebbero fornire handle di Page Layout corrispondenti quando si affidano a layout personalizzati.
• Se sull'installazione di destinazione non esiste un handle di Page Layout corrispondente, il rendering pubblico ricade su un'alternativa sicura.
• Le pagine sorgente nascoste degli Shared Slot restano interne e nel pacchetto non sono trattate come normali pagine rivolte all'utente.
• La cronologia delle revisioni degli Shared Slot è esclusa da esportazione/importazione, in linea con l'attuale confine di portabilità delle revisioni di pagina.

Anche le variabili di sito sono contenuti di sito portabili:

• le righe di site_variables vengono esportate e importate con il pacchetto del sito.
• Chiavi, etichette, valori, ordinamento e stato di attivazione delle variabili sono preservati.
• Il comportamento dei token pubblici non viene valutato durante esportazione o importazione; i valori grezzi sono trasferiti così come sono memorizzati.

Non include dati di runtime globali dell'installazione come utenti, backup, cronologia degli aggiornamenti, sessioni o invii dei moduli di contatto.

Non richiede nemmeno l'indice di ricerca pubblico derivato come contenuto portabile:

• public_search_index è un dato derivato a runtime
• i payload di esportazione/importazione non hanno bisogno delle righe di ricerca per ricreare il sito
• usate php artisan search:rebuild dopo l'importazione quando servono subito righe di ricerca aggiornate

L'importazione di una singola pagina JSON è il flusso di lavoro di amministrazione con ambito di pagina per creare una nuova pagina a partire da un file JSON.

• percorso di amministrazione: Admin -> Pages -> Import Page
• ambito: una nuova pagina in un sito selezionato
• schema: webblocks.cms.page.v1
• risultato: nella V1 crea sempre una nuova pagina in bozza
• nella V1 non aggiorna una pagina esistente
• non importa la cronologia delle revisioni della pagina di origine
• non sostituisce il flusso di lavoro Export / Import a livello di sito

Che cosa importa la V1:

• i campi di base della pagina necessari alla creazione della bozza, incluso il Page Layout a livello di pagina
• traduzioni di pagina indicizzate per codice lingua per le lingue abilitate sul sito di destinazione
• slot di pagina, inclusi i riferimenti shared_slot tramite handle di Shared Slot compatibile dello stesso sito
• alberi di blocchi di proprietà della pagina con ordine annidato padre-figlio
• righe di traduzione dei blocchi supportate per le famiglie di blocchi traducibili
• metadati degli asset di pagina per percorsi locali validi /site/... di CSS e JS

Vincoli della V1:

• i conflitti di percorso tradotto sul sito di destinazione bloccano l'importazione prima delle scritture
• i riferimenti agli Shared Slot devono già esistere sul sito di destinazione ed essere compatibili per sito, stato attivo, shell e nome dello slot
• l'importatore non crea Shared Slots automaticamente
• i valori di schema non supportati vengono rifiutati esplicitamente
• l'importatore è transazionale e non lascia pagine parziali quando la validazione fallisce

Consultate docs/examples/page-import-v1.json per il payload di esempio.

La promozione del sito è il flusso di lavoro basato su pacchetti per promuovere contenuti di proprietà del sito da un pacchetto di origine a un sito di destinazione esistente.

Usatela quando:

• il sito di destinazione esiste già
• contenuti di proprietà del sito richiedono una promozione controllata verso quel sito
• i dati a livello di installazione, specifici dell'ambiente e di runtime live devono essere preservati

In cosa differisce dagli altri strumenti:

• Export / Import crea o gestisce pacchetti di trasferimento del sito e per impostazione predefinita crea un nuovo sito locale da un pacchetto
• La promozione del sito applica il contenuto del pacchetto a un sito di destinazione esistente
• Il clone del sito duplica contenuti di proprietà del sito all'interno dell'installazione corrente, senza pacchetto
• Backup / Restore è ripristino dell'ambiente e può sostituire il database corrente o gli upload
• Gli aggiornamenti cambiano il codice del prodotto CMS e la versione installata, non i contenuti di proprietà del sito

Flusso di lavoro della V1:

• percorso di amministrazione: Admin -> Sites -> Promote
• comandi: site-promotion:inspect, site-promotion:dry-run, site-promotion:apply
• il dry run è obbligatorio prima dell'applicazione
• l'applicazione crea prima un normale backup di sicurezza
• l'applicazione ricostruisce le righe di ricerca derivate del sito di destinazione dopo l'esito positivo

Le aree preservate includono:

• utenti e ruoli
• sessioni, cache, job e code
• backup e cronologia degli aggiornamenti
• report dei visitatori e invii dei moduli di contatto
• domini live e record di dominio del sito
• configurazione dell'ambiente, segreti dell'installazione e token interni
• righe derivate di public_search_index

Strategie supportate:

• additive_update: crea i contenuti di origine mancanti e aggiorna i contenuti di destinazione corrispondenti senza rimuovere i contenuti aggiuntivi della destinazione
• mirror: crea e aggiorna i contenuti di origine corrispondenti, poi archivia, disattiva o rimuove i contenuti di proprietà del sito di destinazione assenti, dove è sicuro farlo nella V1

I flussi di lavoro di migrazione e importazione di siti web specifici dell'installazione appartengono a project/, non al core del CMS.

La ricerca V1 aggiunge una schermata operativa e un comando a livello di installazione per l'indice di ricerca pubblico derivato.

• schermata di amministrazione: Admin -> Maintenance -> Search Rebuild
• comando di ricostruzione: php artisan search:rebuild

La schermata Search Rebuild verifica la copertura dell'indice di ricerca pubblico derivato per le pagine pubblicate per sito e lingua e può ricostruire l'indice in sicurezza quando le righe derivate devono essere aggiornate.

Ambiti di ricostruzione supportati:

• l'intera installazione
• un sito con --site=
• una lingua con --locale=
• una pagina con --page=

La ricostruzione della ricerca non è distruttiva:

• elimina e ricrea soltanto le righe derivate all'interno dell'ambito richiesto
• non modifica contenuti di pagine, blocchi, traduzioni, Shared Slots o media
• non richiede comandi distruttivi di reset del database

System Settings è la schermata compatta di configurazione a livello di installazione. I gruppi modificabili sono suddivisi in card separate e mirate, con proprie azioni di salvataggio; Runtime Information è di sola lettura.

Mantiene:

• Project Name e Project Tagline per il contesto dell'installazione, solo lato amministrazione
• la lingua (locale) predefinita
• il fuso orario
• le righe per pagina degli elenchi di amministrazione, per le schermate di elenco paginate
• la modalità CMS Mail e le impostazioni email personalizzate per le notifiche di proprietà del CMS
• le impostazioni del banner cookie o privacy
• le informazioni sulla versione del prodotto
• le informazioni sull'ambiente

Non controlla:

• le etichette fisse del marchio nell'amministrazione di WebBlocks CMS
• il branding del sito pubblico
• i valori SEO predefiniti del sito pubblico
• la favicon pubblica, l'ambito della ricerca pubblica o la SEO delle traduzioni di pagina
• la posta di autenticazione host/root o l'instradamento del modulo di contatto del sito
• il contenuto del file .env o le variabili d'ambiente

Project Identity aiuta a distinguere un'installazione CMS da un'altra nella topbar di amministrazione e nel titolo del browser. Quei valori rivolti al pubblico risiedono comunque su ciascun sito o traduzione di pagina.

Admin listing rows per page ha come valore predefinito 15, accetta valori numerici personalizzati come 10 o 12 e modifica solo il numero di righe predefinito usato dalle schermate di elenco paginate dell'amministrazione. Non incide sulla paginazione pubblica.

CMS Mail usa per impostazione predefinita la configurazione email dell'ambiente Laravel. Quando la modalità viene cambiata nelle impostazioni personalizzate del CMS, le email di reimpostazione password di proprietà del CMS e le future notifiche di sistema di proprietà del CMS usano le impostazioni email del CMS memorizzate nel database tramite un mailer CMS dedicato. I campi email personalizzati vengono mostrati solo quando è selezionata la modalità email personalizzata del CMS. Le impostazioni email personalizzate del CMS non sovrascrivono .env; disattivando l'email personalizzata del CMS la posta del CMS torna alla configurazione MAIL_* esistente di Laravel. I segreti email memorizzati non vengono mai mostrati in chiaro, gli aggiornamenti con segreto vuoto mantengono il valore memorizzato e la diagnostica riporta i campi sensibili solo come configurati o non configurati. La diagnostica SMTP personalizzata ora avvisa quando le impostazioni di invio richieste sono incomplete o non valide, e i fallimenti di invio della posta di reimpostazione password restituiscono un errore email CMS controllato registrando solo contesto tecnico privo di segreti. La tabella di diagnostica include un'azione Send Test Email per super admin che invia un semplice messaggio di sistema del CMS attraverso lo stesso percorso del resolver di posta del CMS usato per la posta di reimpostazione password di proprietà del CMS, senza includere segreti, token di reimpostazione o dump grezzi della configurazione.

Site Clone duplica i contenuti di proprietà di un sito da un sito a un altro all'interno della stessa installazione.

Usate Site Clone quando:

• vi serve un secondo sito all'interno dell'installazione corrente
• volete duplicare la struttura di pagine, slot, blocchi, navigazione e lingue (locale) senza creare prima un pacchetto di esportazione
• volete che gli Shared Slot e le assegnazioni di slot di pagina basate su Shared Slot si spostino insieme al sito clonato

Site Clone è diverso da Export / Import:

• Site Clone opera all'interno dell'installazione corrente
• Export / Import serve a spostare un pacchetto di sito tra installazioni diverse
• Sia Site Clone sia Export / Import includono Shared Slot, alberi di blocchi degli Shared Slot, traduzioni, riferimenti ai media e impostazioni di Page Layout a livello di pagina, rimappando inoltre gli slot di pagina che li consumano sugli Shared Slot del sito di destinazione invece di lasciare riferimenti tra siti diversi
• Sia Site Clone sia Export / Import includono anche le site_variables con ambito di sito.
• La cronologia delle revisioni degli Shared Slot non viene clonata, in linea con l'attuale limite di clonazione delle revisioni di pagina.

• occorre ripristinare una pagina
• vi serve un recupero editoriale all'interno dell'installazione corrente

• l'ambiente necessita di un ripristino
• il database o i file caricati devono essere riportati indietro insieme

• occorre spostare un sito in un'altra installazione
• vi serve un pacchetto portabile per un sito

• dovete duplicare un sito in un altro sito all'interno della stessa installazione
• volete mantenere il lavoro nell'ambiente corrente

• state applicando una release pubblicata del CMS all'installazione corrente

• aggiornamenti, backup, ripristino e strumenti di trasferimento dei siti sono funzionalità a livello di installazione
• pagine, media, navigazione e flusso di lavoro editoriale sono principalmente funzionalità di contenuto con ambito di sito
• gli utenti sono account a livello di installazione, anche quando alcuni ruoli sono limitati ai siti assegnati
• il packaging delle release e la conservazione dei percorsi installati sono aspetti distinti: le release non distribuiscono project/, mentre il contenuto di project/ già installato viene conservato tra un aggiornamento e l'altro