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 contiene la panoramica consolidata insieme agli strumenti operativi esistenti:

• Stato del sistema
• Ricostruzione dell’indice di ricerca
• Backup
• Pulizia
• Esportazione / Importazione
• Aggiornamento

Poiché CMS 1.98.0, Manutenzione → Integrità del sistema fornisce un punto in cui rivedere l'installazione e i suoi siti. Per gli utenti con accesso System Health, la Dashboard mostra un riepilogo compatto dei controlli che richiedono azioni, che meritano di essere revisionati o non ancora verificati, con un collegamento alla panoramica completa. I conteggi zero mostrano che non sono stati rilevati problemi nei controlli disponibili. La pagina inizia con i conteggi e gli elementi più urgenti, seguiti dalle schede per Sistema, Siti, Backup, Lavoro pianificato, Archiviazione, Ricerca, Plugin e Aggiornamenti. Ogni elemento spiega il passaggio successivo e si collega allo strumento esistente. I dettagli tecnici, i risultati recenti di backup/ripristino/aggiornamento e i valori delle informazioni di sistema esistenti vengono raggruppati per impostazione predefinita.

La scheda Notifiche pianificate include l'avviso dettagliato della pianificazione, l'effetto sulle e-mail in sospeso, UTC orari per l'ultimo heartbeat pianificato e l'esecuzione della notifica completata, istruzioni di configurazione e un collegamento alla guida di installazione. I collegamenti Revisione pianificazione aprono questa sezione e mantengono il filtro del sito selezionato. I responsabili delle operazioni del sito che non possono accedere all'integrità del sistema conservano la scheda di pianificazione dettagliata con ambito del sito nella dashboard e nelle impostazioni dei contatti del sito. Il riepilogo della casella di posta delle notifiche del Pannello rimane sulla Dashboard.

Gli stati distinguono tra regolare, da verificare, urgente, non ancora verificato e non applicabile. Un controllo non disponibile non viene indicato come regolare. I controlli di ricerca confrontano le coppie idonee di pagina pubblicata e lingua con la copertura dell’indice; non certificano l’aggiornamento del testo. I controlli dei backup riguardano i record recenti riusciti e la disponibilità degli archivi; non certificano l’integrità del ripristino. L’idoneità all’aggiornamento è distinta dallo stato dell’installazione e la disponibilità delle versioni usa un risultato recente dell’aggiornamento memorizzato nella cache. Aprire Aggiornamenti per richiedere un nuovo controllo delle versioni.

I controlli del sito vengono memorizzati nella cache per cinque minuti; la schermata Stato del sistema legge le prove registrate dalla pianificazione ad ogni visita. Dashboard, Backup e Pulizia mostrano l'ultimo report completato con il relativo tempo di misurazione. Non analizzano il backup SQL durante l'apertura. I report mancanti non vengono verificati e i report vecchi o invalidati vengono esplicitamente contrassegnati come obsoleti. Le impostazioni rimangono disponibili prima del primo report. Le schede Archiviazione e cronologia e Azioni di pulizia spiegano i report non disponibili e offrono Controlli di aggiornamento direttamente; un aggiornamento riporta alla stessa scheda. Il pulsante di aggiornamento mostra l'attività durante l'invio e il risultato conferma il completamento, segnala che un altro aggiornamento è già in esecuzione o mostra un messaggio di errore. Gli aggiornamenti di integrità del sistema mantengono il filtro del sito selezionato.

Le voci della cache del report di manutenzione contengono array con versione e valori scalari, pertanto le installazioni possono mantenere disabilitata la deserializzazione degli oggetti della cache. I controlli di aggiornamento confermano il successo solo dopo aver riletto l'esatta istantanea scritta. Un errore di verifica della cache mostra un errore e tenta di conservare il report completato precedente; le decisioni di conservazione mancanti sui backup vengono visualizzate come anteprime non disponibili anziché come requisiti di aggiornamento dello schema. Dopo un aggiornamento del prodotto, il primo report per quella versione viene generato dai controlli di aggiornamento o dallo scheduler.

Lo scheduler Laravel esegue php artisan system:reports:refresh ogni cinque minuti. I controlli di aggiornamento sull'integrità del sistema possono anche eseguire questo lavoro manualmente. Ogni chiamata convalida al massimo otto archivi di backup del piano di ripristino esistenti, quindi aggiorna il report condiviso; un'installazione di grandi dimensioni potrebbe richiedere diverse invocazioni per completare la convalida iniziale. I nuovi backup e caricamenti registrano la convalida quando vengono creati. La convalida in sospeso nega l'idoneità alla pulizia nel rapporto del panel. È necessario uno scheduler funzionante per l'aggiornamento automatico; l'apertura di una pagina non avvia un aggiornamento sincrono. I report memorizzati nella cache non sostituiscono mai gli attuali controlli di sicurezza eseguiti prima della pulizia o del ripristino. L'ultimo report completato viene conservato per un massimo di sette giorni e viene visualizzato come non aggiornato dopo cinque minuti. Il filtro del sito restringe i controlli relativi al sito mantenendo i controlli a livello di installazione. La panoramica non esegue la pulizia, ricostruisce la ricerca, avvia i backup, installa gli aggiornamenti o crea prove della pianificazione. I siti esistenti e le pagine di manutenzione operativa rimangono disponibili. Da CMS 1.98.1, la schermata separata Informazioni di sistema e il collegamento della barra laterale vengono rimossi; i suoi nove campi di informazioni di runtime rimangono in Integrità del sistema → Dettagli del sistema e /webadmin/system/information reindirizza a Integrità del sistema con lo stesso requisito di accesso al sistema. La guida è un collegamento diretto alla documentazione a https://cms.webblocksui.com/docs; le destinazioni dei plugin precedentemente fornite alla Guida rimangono raggiungibili in Sistema.

L’endpoint di sola lettura dell’API interna è GET /webadmin/api/system/health, con il parametro facoltativo site_id. Richiede la capacità system-health.read concessa esplicitamente a un token di sistema senza restrizioni il cui creatore attivo disponga attualmente dell’accesso al Sistema. I token personali e limitati ai siti non possono leggere lo stato dell’intera installazione. Le risposte usano messaggi controllati ed esiti normalizzati invece di testi delle eccezioni, log delle operazioni, percorsi degli archivi o segreti dei plugin. Consultare API interna dei contenuti per il contratto della risposta.

I rapporti sui visitatori forniscono riepiloghi operativi dell'attività della pagina pubblica. I record di visualizzazione delle pagine di base non richiedono identificatori basati sul consenso. I record includono informazioni ridotte su referrer, campagna, dispositivo 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.

Da CMS 1.105.26, la finestra di dialogo di avanzamento mostra una fase corrente tradotta mentre l'esecuzione è confermata. Il titolo identifica la versione di destinazione senza implicare che il lavoro sia ancora in esecuzione dopo il completamento. Quando il tracciamento si interrompe o il risultato diventa terminale, la fase, l'indicatore di avanzamento e l'avviso di attesa scompaiono insieme; il tempo trascorso e il risultato rimangono visibili. Il successo confermato ritorna automaticamente agli Aggiornamenti. I risultati degli errori o del backup ripristinato rimangono disponibili per la revisione. Gli identificatori di fase sconosciuti utilizzano un fallback leggibile invece di una chiave di traduzione.

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 è un clic. Una singola azione Update to X scarica il pacchetto di rilascio, esegue un backup automatico prima dell'aggiornamento, applica le regole del percorso protetto, esegue le migrazioni di aggiornamento del pacchetto richieste, cancella le cache, verifica la versione del codice WebBlocks CMS applicata rispetto alla versione di destinazione, registra l'esecuzione dell'aggiornamento e rende persistente la versione installata. Se l'applicazione fallisce, il programma di aggiornamento ripristina automaticamente il backup pre-aggiornamento e registra l'esecuzione con lo stato restored; se anche il ripristino automatico fallisce, la corsa viene registrata come failed con entrambe le tracce di errore. Per il ripristino manuale, il backup pre-aggiornamento rimane nella schermata Backup per il download e il ripristino e php artisan system:backup:restore esegue un ripristino CLI.

Maintenance → Cleanup possiede criteri di conservazione a livello di installazione. I controlli del ciclo di vita riportati di seguito sono disponibili in CMS 1.105.12.

Le policy salvate esistenti, inclusa la conservazione della sicurezza di ripristino di 30 giorni, rimangono invariate. La protezione dell'età e del conteggio si applica insieme. Solo gli archivi fisici distinti e disponibili, strutturalmente convalidati contano ai fini del numero minimo di archivi validi riusciti di un tipo. Un backup scaduto può rimanere protetto da quel conteggio minimo. Gli archivi non riusciti/mancanti non sostituiscono i punti di ripristino validi. I backup in esecuzione e i punti di ripristino associati ai recenti aggiornamenti non riusciti/ripristinati rimangono protetti.

Utilizzare l'icona di blocco/impostazioni su Backup per gestire il flag Protetto di un archivio e la sua modalità policy, never o expires. La protezione blocca l'eliminazione singola, forzata e collettiva fino alla rimozione. La modalità indefinita impedisce la scadenza automatica ma consente comunque l'eliminazione esplicita. La scelta di una data attiva esplicitamente la pulizia dell'archivio, inclusi gli archivi manuali e caricati; si applicano ancora la protezione e i conteggi minimi riusciti. Le date seguono il fuso orario dell'applicazione. La finestra di dialogo di creazione manuale registra la protezione/conservazione selezionata prima dell'acquisizione SQL.

Il budget opzionale è misurato in GiB (1024³ byte), per impostazione predefinita non è impostato, avvisa al 80% e segnala un superamento al 100%. Non sovrascrive mai la protezione o la conservazione. I backup e la pulizia mostrano lo spazio di archiviazione fisico totale, i byte protetti in modo esplicito, i byte idonei, lo spazio di archiviazione stimato dopo la pulizia e l'eventuale sovraccarico rimanente. I file non registrati vengono conteggiati nell'utilizzo del disco ma non vengono mai selezionati automaticamente. Le misurazioni parziali/non disponibili sono esplicite. Un archivio condiviso non viene conteggiato più volte e l'eliminazione di un record non scollega mai il file di un altro record.

Spiegazione dell'archiviazione (CMS 1.105.13): la scheda di conservazione del backup nella scheda Archiviazione e cronologia di Cleanup e l'elenco dei backup aggiunge una tabella dei motivi. Mostra i conteggi dei record di backup, i conteggi distinti dei file fisici e i byte misurati per la protezione del conteggio minimo, i periodi di conservazione, la protezione esplicita, la conservazione a tempo indeterminato, la pulizia manuale disabilitata e altre decisioni attuali. Gli archivi idonei vengono visualizzati separatamente. Le regole di età e di conteggio minimo proteggono entrambe i backup; "mantieni l'ultima N" è un limite, non un limite, al numero totale conservato.

I file di archivio condivisi contribuiscono con byte una volta sotto il primo motivo applicabile nella tabella. I conteggi dei record seguono comunque lo stato di ciascun record, quindi un motivo potrebbe includere record senza byte fisici aggiuntivi. Gli altri file nell'archivio di backup, inclusi i file di blocco o di supporto, vengono visualizzati separatamente e non vengono mai rimossi automaticamente. Una scansione parziale mostra dimensioni di archivio note con totali non confermati e dimensioni di altri file contrassegnate come non disponibili. La pulizia del backup esistente API include la stessa suddivisione in preview.overview.reason_summary.

La pulizia del backup viene eseguita ogni giorno alle 03:30 con l'impostazione abilitata esistente. Il pacchetto non richiama la pulizia del backup dopo un aggiornamento riuscito; per la sua esecuzione automatica è richiesto uno scheduler host funzionante. Anteprima con php artisan system:backups:cleanup --dry-run -v; l'esecuzione normale utilizza la stessa politica. --force ignora solo l'impostazione abilitata. Non ignora mai la protezione, i conteggi minimi o le operazioni attive. L'invocazione dello scheduler aggiunge --scheduled per registrare la sua fonte. Le anteprime di sola lettura non creano cronologia di esecuzione o root del disco; le esecuzioni completate registrano un risultato limitato SQL con i byte effettivamente eliminati.

Un comune lease del filesystem non bloccante serializza la creazione, il caricamento, il ripristino, le modifiche alla conservazione e l'eliminazione del backup. Sopravvive al ripristino SQL e viene rilasciato all'uscita del processo. I file system di backup condivisi devono supportare i blocchi di file consultivi. Sono necessarie le migrazioni dei pacchetti correnti. La manutenzione di ripristino ripara lo schema di conservazione/riepilogo aggiuntivo quando uno snapshot precedente SQL lo precede.

L’API interna mantiene GET/PUT /webadmin/api/system/backup-cleanup con backups.read / backups.settings.write e il POST distruttivo /webadmin/api/system/backup-cleanup/run con backups.delete. I campi originali restano obbligatori; i campi opzionali del ciclo di vita modificano soltanto i valori inviati e preservano quelli omessi. Null in budget_gb rimuove il budget. GET/PUT /webadmin/api/system/backups/{backup}/retention legge o imposta protezione e scadenza con le stesse capacità separate di lettura e scrittura delle impostazioni. Consultare il contratto di discovery dell’API per campi obbligatori e modalità valide. La copia su archiviazione remota resta una fase successiva.

L'area di lavoro Pulitura mostra i conteggi dei file fisici e i byte per backup di sistema, pacchetti di esportazione/importazione, caricamenti pubblici escluse le varianti generate, varianti generate, aree di lavoro temporanee note, file di revisione delle risorse, file pubblici del sito e registri delle applicazioni standard. Le misurazioni riportano il timestamp e distinguono le directory mancanti, le scansioni parziali e lo spazio di archiviazione non disponibile. Non misurano la quota di hosting o le tabelle del database allocate. Sono escluse le posizioni dei log personalizzati; Le root del disco condiviso potrebbero causare la sovrapposizione delle categorie, quindi non aggiungerle a una quota a livello di installazione. Le dimensioni di revisione esistenti per sito descrivono separatamente i payload degli snapshot logici. Un'anteprima della pulizia non disponibile viene mostrata esplicitamente.

Le cinque categorie sono asset-revisions, media-variants, temporary-workspaces, page-revisions e shared-slot-revisions. Per le revisioni delle risorse sono protetti per impostazione predefinita almeno 90 giorni di cronologia e le ultime 20 revisioni per risorsa. Per gli spazi temporanei il periodo predefinito è 24 ore. Per le revisioni di pagine e Shared Slot restano protetti almeno 90 giorni e le ultime 50 revisioni per proprietario, oltre alle fonti usate nei ripristini di revisione attivi. I file originali della libreria multimediale e le impronte delle varianti correnti non sono mai selezionabili per la pulizia delle varianti. Archivi di trasferimento e registri restano gestiti dall’operatore.

L'età di revisione e la protezione del conteggio minimo si applicano insieme. Ad esempio, una pagina con 20 revisioni conserva tutte le 20 anche se sono più vecchie di 90 giorni, poiché le ultime 50 sono protette. Le policy salvate esplicite, inclusa la conservazione di 365 giorni, vengono preservate; solo il fallback per un'impostazione non configurata cambia in 90 giorni. Il salvataggio delle impostazioni aggiorna l'idoneità e il successivo lavoro pianificato abilitato può applicarla.

Da CMS 1.105.25, Politica di conservazione raggruppa le pianificazioni delle categorie, la conservazione del backup e la conservazione delle revisioni/area di lavoro nelle tabelle reattive. Per conservazione si intende una soglia di età più il conteggio minimo protetto, non un conteggio massimo di backup. L'inclusione del backup manuale e il budget di archiviazione rimangono controlli separati; un budget non prevale mai sulla protezione. I valori salvati esistenti vengono conservati durante l'aggiornamento e dopo gli errori di convalida.

Il collegamento Configurazione e verifica dello strumento di pianificazione apre una schermata autorizzata di sola lettura con comandi specifici dell'installazione e prove di heartbeat registrate. Supporta l'hosting standard cron senza Herne, oltre alla configurazione opzionale confermata CLI per l'account dell'applicazione. Vedere impostazione della pianificazione. L'aggiunta di una voce cron non costituisce prova dell'esecuzione. Aggiorna dopo 1–2 minuti per verificare l'attività effettiva; la pulizia viene comunque eseguita secondo la pianificazione mostrata nella tabella.

L'area di lavoro utilizza schede native per Archiviazione e cronologia, Conservazione e automazione e Azioni di pulizia. Le impostazioni utilizzano gruppi denominati WebBlocks UI con campi età/conteggio accoppiati, senza HTML frame set di campi/legenda. I reindirizzamenti di convalida/azione mantengono il pannello pertinente. Le azioni dell'ingranaggio della cronologia conservata aprono la scheda delle impostazioni nella politica di revisione pertinente e l'azione dell'occhio apre la gestione dei pacchetti di trasferimento. Tutti utilizzano le azioni standard delle icone del pannello con etichette accessibili. Le categorie vuote mostrano uno stato neutro "Niente da pulire"; le categorie con articoli idonei mantengono la modalità di conferma distruttiva esistente. La selezione automatica mostra l'orario programmato di ciascuna categoria.

Eseguire le migrazioni attuali di installazione o aggiornamento prima di usare i nuovi riepiloghi. Ogni categoria registra soltanto l’ultimo risultato manuale o pianificato, con inizio, fine, ultimo successo, conteggi, byte ed errori. Una cancellazione parziale conteggia soltanto i byte realmente rimossi. Se manca lo schema del riepilogo, la pulizia è bloccata; un vecchio riepilogo di esecuzione in corso appare interrotto. Letture dei rapporti e simulazioni non creano prove di esecuzione o attività del pianificatore.

Abilita le categorie pianificate individualmente in Manutenzione → Pulizia. I nuovi flag sono disattivati ​​per impostazione predefinita. I programmi giornalieri eseguono revisioni delle risorse in 04:00, varianti multimediali obsolete in 04:10 e spazi di lavoro temporanei in 04:20. La pulizia delle revisioni di pagina e Shared Slot viene eseguita la domenica alle ore 04:30 e 04:45. Gli orari seguono il fuso orario di pianificazione dell'applicazione. L'host deve eseguire Laravel Scheduler e utilizzare una cache condivisa con blocchi atomici quando operano più lavoratori. L'eliminazione della revisione della scrittura delle risorse esistente continua a essere applicata dopo le modifiche alle risorse anche quando la pianificazione giornaliera aggiuntiva è disattivata. La pulizia del backup esistente ha una politica e una pianificazione separate.

La pulizia temporanea copre il timestamp riconosciuto/UUID esecuzioni di aggiornamento e le esecuzioni provvisorie di backup/ripristino abbandonate in storage/app/temp/system-backups e storage/app/temp/system-backup-restores. Ogni voce nidificata deve essere precedente alla soglia di conservazione. L'impostazione predefinita rimane 24 ore; abbassarlo non è necessario per recuperare il lavoro abbandonato. L'identità di installazione, i file sconosciuti o i nomi di esecuzione, le cartelle di ripristino-backup del programma di aggiornamento, gli alberi con collegamenti simbolici e gli archivi di backup sovrapposti o i caricamenti pubblici vengono conservati. L'utilizzo fisico include i file conservati, quindi lo spazio di archiviazione misurato può essere diverso da zero senza alcun candidato idoneo.

La cronologia degli aggiornamenti obsoleti running/pending di per sé non blocca più la pulizia. Le ammissioni recenti, i nuovi battiti cardiaci, i lavori degli operatori in coda e gli effettivi blocchi degli aggiornamenti in sospeso continuano a proteggere il lavoro. I lease dei processi di backup/ripristino proteggono anche le operazioni il cui snapshot del database è già indicato completed. La cancellazione mantiene sia i contratti di locazione operativa che ricontrolla l'età e l'identità dell'albero; non riscrive la cronologia degli aggiornamenti. Se non è possibile scrivere e rileggere l'heartbeat del lease, la pulizia si interrompe in modo sicuro. I download del catalogo utilizzano lease di file durante l'installazione; sono idonei solo i file temporanei catalog-plugin- scaduti e sbloccati. Gli altri file in quella directory non sono selezionati. La pulizia temporanea automatica rimane un'opzione esplicita per installazione in Conservazione e automazione; abilitandola non cambia il limite di età né gli altri flag di categoria.

L'ultimo modulo viene eseguito solo se per quella categoria è abilitata la manutenzione automatica. Utilizzare uno qualsiasi dei cinque nomi di categoria per l'argomento categoria. Un'esecuzione di prova non rimuove mai file né scrive un riepilogo dell'esecuzione; i comandi restituiscono un errore quando la pulizia o la relativa anteprima non possono essere completate.

L'Interno API espone GET e PUT /webadmin/api/system/cleanup fino a maintenance.read e maintenance.settings.write, più il distruttivo POST /webadmin/api/system/cleanup/{category}/run fino a maintenance.delete. I campi di conservazione esistenti rimangono obbligatori durante la scrittura delle impostazioni. Le patch opzionali per gli oggetti automatic denominate flag di categoria booleana; i flag omessi mantengono i loro valori. La risposta di lettura aggiunge misurazioni fisiche e risultati più recenti in overview.storage_report e overview.automation. Flag sconosciuti e valori non booleani vengono rifiutati. Un'esecuzione non riuscita restituisce ok: false e un conteggio degli errori anziché dichiarare una pulizia riuscita.

La disponibilità degli aggiornamenti si basa sul fatto che l'ultima versione pubblicata è più recente della versione del codice CMS in esecuzione. Le esecuzioni cronologiche degli aggiornamenti non riusciti e i valori delle versioni installate memorizzate non aggiornate rimangono ispezionabili tramite i dettagli dell'esecuzione modali e mantenuti-eseguiti CLI, ma non rendono l'installazione corrente utilizzabile da soli.

Lo schermo è un'unica scheda di stato. Quando è disponibile un aggiornamento compatibile, mostra il percorso della versione da corrente a quella più recente, un'area del registro delle modifiche ripiegata What's new, l'azione con un clic Update to X con una nota di backup e un avviso di backup del server che si collega alla schermata Backup in modo che gli operatori eseguano un nuovo backup completo prima di un aggiornamento importante. Quando non è disponibile alcun aggiornamento, mostra un messaggio di aggiornamento silenzioso con la versione installata e l'ora dell'ultimo controllo.

I super amministratori dispongono di un indicatore di aggiornamento asincrono nella barra superiore dell'amministratore. È nascosto per impostazione predefinita, controlla lo stato degli aggiornamenti in modo asincrono e diventa visibile solo quando è disponibile una versione attendibile più recente.

La preparazione al preflight è un elenco di controllo pass/fail esplicito sullo schermo: connessione al database, estensioni ZIP e sodio PHP, esecuzione PHP/Composer/processo, accesso in scrittura alla root dell'applicazione e all'area di lavoro di aggiornamento e spazio libero su disco. L'azione di aggiornamento è disponibile solo quando ogni controllo viene superato e nessun'altra esecuzione di aggiornamento mantiene il blocco.

La cronologia degli aggiornamenti esegue il rendering delle esecuzioni conservate come una fisarmonica chiusa; ogni esecuzione apre il proprio registro in modo modale e l'eliminazione delle righe non fa parte dell'amministrazione UI. I record delle esecuzioni di aggiornamento vengono eliminati automaticamente, conservando le ultime cinque esecuzioni per impostazione predefinita. L'ultima esecuzione non riuscita viene conservata finché non esiste una nuova esecuzione riuscita. 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 l'eliminazione controllata con php artisan webblocks:updates:prune-runs --keep=5.

Il client di aggiornamento supporta metadati strutturati dal servizio di aggiornamento, inclusi titolo, riepilogo, evidenziazioni, correzioni, note di compatibilità, note di migrazione, note sulle risorse, note dell'operatore e note tecniche, oltre a voci cumulative del registro delle modifiche per versione per la fisarmonica What's new. La preparazione della versione nativa CMS deriva il riepilogo e i punti salienti dalla sezione della versione CHANGELOG.md corrispondente e aggiunge metadati tecnici specifici della versione, quindi la scheda della versione dovrebbe descrivere la versione effettivamente pubblicata anziché i segnaposto ripetuti del flusso di lavoro di pubblicazione. Questi valori vengono visualizzati come testo semplice con escape. Le versioni precedenti che forniscono solo release_notes mostrano ancora quelle note in modo chiaro, mentre le versioni senza note mostrano No release notes were provided for this release.

La sincronizzazione del catalogo spedito viene eseguita automaticamente come passaggio ottimale della catena di applicazione degli aggiornamenti (webblocks:catalog-repair --all); un errore di sincronizzazione non interrompe l'esecuzione dell'aggiornamento e può essere riparato manualmente in seguito.

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

webblocks:catalog-repair supporta --block-types, --plugin-block-types, --slot-types, --page-layouts, --icons e --all. Segnala le righe create, aggiornate, non modificate e saltate, conserva le righe del catalogo personalizzato specifiche dell'installazione e può essere eseguito ripetutamente. block-types:sync-core rimane come comando di compatibilità subordinato per il catalogo dei tipi di blocco.

--plugin-block-types scrive una riga di catalogo per ogni tipo di blocco dichiarato da un plugin installato, abilitato o meno, quindi il blocco è posizionabile nell'editor; i blocchi di un plugin disabilitato vengono comunque filtrati dai selettori da PluginBlockCatalog. Le azioni del ciclo di vita del plug-in (installazione, abilitazione, disabilitazione, configurazione, aggiornamento) eseguono già questa sincronizzazione tramite PluginRuntimeRefresher, quindi l'ambito è un percorso di riparazione anziché quello normale. Una risincronizzazione corregge le colonne di proprietà del plugin (name, description, source_type, is_system, is_container) e lascia deliberatamente da sole category, sort_order e status, in modo che la cura dell'operatore (riprogrammazione di un blocco, riordino o impostazione in bozza per nasconderlo) sopravviva alla riparazione.

I pacchetti di rilascio pubblicati contengono il runtime riutilizzabile CMS: origine, risorse pubbliche, migrazioni, visualizzazioni, percorsi, configurazione, file di lingua e stub di installazione. Test di sviluppo, script, metadati del repository, configurazione locale, fonti di documentazione e contenuto di progetto specifico per l'installazione sono esclusi dall'archivio di distribuzione. La documentazione canonica è mantenuta nel suo archivio indipendente.

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

release:push invia il ramo di rilascio e il tag annotato a origin in un push Git, quindi la suite di convalida pre-push viene eseguita una volta. Quindi rispecchia i riferimenti verificati su backup senza rieseguire quell'hook. release:prepare costruisce il pacchetto ZIP, il checksum e il payload Publisher dal commit HEAD; richiede un albero pulito, una versione sorgente corrispondente, l'esatto tag annotato v{VERSION} e un inventario rivisto con la provenienza della documentazione corrispondente.

Esegui i controlli locali e verifica il commit di rilascio GitHub CI prima della pubblicazione. release:publish-update -- --dry-run convalida l'artefatto e la configurazione senza caricare. Il comando di pubblicazione effettivo richiede l'autenticazione GitHub CLI, firma e carica l'artefatto su Publisher, verifica i metadati del canale stabile e pubblica o aggiorna la versione GitHub corrispondente. Publisher rimane l'origine dell'aggiornamento dell'installazione; una versione GitHub da sola non pubblica il canale di aggiornamento CMS. Se una risposta viene interrotta, controllare entrambi gli stati di pubblicazione prima di riprovare.

La pubblicazione del manutentore richiede WEBBLOCKS_PUBLISHER_TOKEN e WEBBLOCKS_PUBLISHER_SIGNING_KEY, caricati al momento dell'esecuzione dalla configurazione stabilita dal manutentore. Non copiare queste credenziali in un'installazione o documentazione CMS. I siti installati utilizzano il server di rilascio di proprietà del pacchetto, il prodotto e le impostazioni predefinite del canale stabile; le installazioni ordinarie non necessitano di Publisher impostazioni dell'ambiente del server o del canale. Il precedente bridge updates.webblocksui.com è storico e non è un percorso di configurazione attivo.

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 modulo di contatto vengono salvati prima della consegna della notifica. Lo stato della notifica via email riflette solo il comportamento della notifica e non modifica la classificazione editoriale. Sent significa che Laravel ha accettato l'invio tramite un trasporto di posta reale configurato senza eccezioni; non garantisce la consegna della posta in arrivo. Failed significa che un vero tentativo di notifica ha generato un errore disinfettato. Skipped o Not configured significa che non si è verificato alcun invio reale. Gli invii validi vengono classificati come consentiti, messi in quarantena o spam; la quarantena e lo spam vengono conservati per la revisione con la notifica soppressa. Una prova firmata non valida, un campo di controllo generato riempito o un invio al di sotto del tempo minimo rigido seguono il successo generico senza archiviazione. Il riepilogo della protezione in sequenza conteggia solo le richieste che hanno raggiunto il punteggio. Consulta Protezione dell'invio pubblico per segnali, soglie, limiti di privacy e ottimizzazione.

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. Esaminare i totali di protezione di 30 giorni e correggere i falsi positivi tramite lo stato.
6. Eseguite php artisan contact:mail-diagnose --block=ID se la risoluzione del destinatario non è chiara.
7. 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
• Caricamenti gestiti da CMS da storage/app/public, esclusi i file rigenerabili media/transforms/ nei nuovi backup
• file pubblici del sito da public/site
• 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

I nuovi backup registrano excluded_upload_paths: ["media/transforms/"] nel manifest della versione uno. Le immagini originali, gli allegati e altri caricamenti rimangono nell'archivio. Le varianti generate vengono ricostruite quando il renderer ne ha bisogno dopo il ripristino; i codec assenti tornano all'originale. La ricostruzione anticipata di tutte le varianti è facoltativa; vedere Varianti dell'immagine multimediale. Gli archivi della versione precedente e quelli legacy rimangono ripristinabili, comprese le varianti memorizzate nella cache quando presenti. I backup nello stesso secondo hanno nomi di file distinti, pertanto l'archivio di sicurezza pre-ripristino non può sovrascriverne l'origine.

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
• fuso orario, che è l'impostazione predefinita a livello di installazione e il fallback per qualsiasi sito che non ne imposta uno proprio
• 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

I rapporti sui visitatori ora ricavano un grafico temporale, un confronto di periodo precedente di pari lunghezza, una copertura di misurazione e modalità di dettaglio della pagina dai record esistenti. Non aggiunge script pubblici, cookie, identificatori, eventi o trasferimenti di terze parti. Le decisioni di consenso esistenti continuano a disciplinare la raccolta degli identificatori.

• I grafici riempiono i giorni mancanti con zero visualizzazioni registrate. Gli intervalli più lunghi di 90 giorni utilizzano intervalli di più giorni di uguali dimensioni, etichettati nel grafico e nella tabella dei valori accessibili, aperti con il pulsante dei valori del grafico in modalità WebBlocks UI. Le date utilizzano lo stesso calendario dell'applicazione/database dei report esistenti.
• Il periodo precedente termina immediatamente prima del periodo selezionato. Un totale precedente pari a zero non presenta alcuna variazione percentuale. I periodi che includono date attuali o future sono etichettati come provvisori. I conteggi descrivono i record conservati, non la prova che il monitoraggio fosse continuamente attivo o che un periodo storico vuoto non avesse visitatori.
• La copertura è la quota di visualizzazioni con un identificatore utilizzabile basato sul consenso nei record di dettaglio conservati. Non è non un tasso di accettazione del consenso. Le stime dei visitatori/sessioni descrivono questo sottoinsieme e non sono conteggi verificati di persone.
• Lo stato del monitoraggio mostra l'ultimo record dettagliato nell'ambito del sito selezionato accessibile, indipendentemente dalla data, dalle impostazioni locali e dai filtri del traffico. Non afferma che lo scheduler sia in esecuzione o che i record assenti dimostrino un errore di tracciamento.
• Le righe di contenuto aprono WebBlocks UI modalità con i totali di pagina/sito/impostazione internazionale e suddivisioni indipendenti per dispositivo/referrer. Un'intera suddivisione viene nascosta se un gruppo ha meno di cinque visualizzazioni, evitando la sottrazione diretta di una cella soppressa. Questa è una salvaguardia della visualizzazione, non una garanzia di anonimizzazione. Non vengono aggiunti viaggi individuali. I dieci gruppi più grandi vengono visualizzati quando è disponibile una suddivisione.

Il report segue il contratto della barra filtro etichettato WebBlocks UI, con metriche di riepilogo sopra il grafico e schede del report dettagliate sotto. La copertura della misurazione, lo stato del monitoraggio, il contesto della privacy e la politica di conservazione sono disponibili nella modalità Informazioni sul rapporto. Gli avvisi sulle migrazioni mancanti, sulla pulizia disabilitata e sui record archiviati rimangono visibili nel report stesso.

Il grafico utilizza come origine il componente WebBlocks UI 2.26.0 wb-chart in bundle e la tabella modale visitor-chart-data. Gli attributi numerici contengono conteggi non formattati; le celle visibili mantengono la formattazione localizzata. UI possiede SVG disegno, assi, ridimensionamento e interazione con la tastiera; CMS mantiene query, autorizzazioni, privacy e aggregazione. Non viene introdotta alcuna libreria di grafici esterna o raccolta di visitatori aggiuntiva.

Il pacchetto registra visitors:cleanup ogni giorno dallo Scheduler da 03:45 a Laravel. L'host deve eseguire il normale scheduler; nessuna richiesta pubblica esegue la pulizia. Il comando pianificato e il comando manuale condividono un blocco della cache atomica. Utilizzare una cache condivisa con funzionalità di blocco durante la pianificazione su più server.

Si tratta di impostazioni predefinite del prodotto, non di requisiti di conservazione legale o di certificazione di conformità legale. I proprietari dei siti possono scegliere periodi più brevi per i loro scopi. Le installazioni esistenti con una pianificazione funzionante iniziano ad applicare questo criterio dopo l'installazione della nuova migrazione e del codice. Non è prevista alcuna eliminazione all'interno della migrazione stessa.

Anteprima ed esecuzione locale sull'host:

La pulizia viene eseguita anche quando la raccolta delle nuove visite è disabilitata. La disabilitazione della raccolta non deve lasciare gli identificatori storici archiviati a tempo indeterminato. La disabilitazione della pulizia stessa viene mostrata nel report. Le migrazioni di riepilogo mancanti bloccano la pulizia senza eliminare i record e lasciano operativi i report esistenti.

I record scaduti vengono sostituiti a livello transazionale, un giorno alla volta, con righe in wbcms_visitor_daily_totals: sito, impostazioni internazionali (zero per sconosciuto), giorno, visualizzazioni totali e visualizzazioni bot. Non conservano alcun percorso della pagina, referrer, campagna, dispositivo, ora esatta della visita, IP hash o identificatore di sessione. I record tardivi si uniscono ai totali esistenti una volta. I record più vecchi dell'orizzonte di conservazione totale, i record senza data e i record scaduti il ​​cui sito è stato eliminato vengono eliminati senza un rollup. L'eliminazione di un sito rimuove anche i suoi totali giornalieri. I backup esistenti hanno il proprio ciclo di vita di conservazione; questo comando non riscrive gli archivi di backup.

I totali principali, il grafico e il confronto combinano i dettagli conservati con i totali giornalieri e preservano l'autorizzazione del sito più i filtri sito/locale/traffico. I totali dei bot includono entrambe le fonti. Le tabelle dettagliate e le metriche di sessione utilizzano solo i record di dettaglio rimanenti; un avviso esplicito spiega la differenza quando un periodo include rollup. I visitatori o le sessioni uniche giornaliere non vengono deliberatamente sommate nei giorni. Il rapporto non ricostruisce mai la storia dei visitatori dai riepiloghi conservati.

Le nuove installazioni e le migrazioni degli aggiornamenti delle installazioni esistenti creano entrambe la tabella dei totali. Eseguire il normale flusso di migrazione/aggiornamento del pacchetto prima di abilitare la pulizia pianificata. Le nuove stringhe di insight vengono fornite in inglese e turco; altre impostazioni locali di amministrazione utilizzano il normale fallback inglese laddove una traduzione di insight non è disponibile.