Transizione all'architettura a pacchetto

Attualmente WebBlocks CMS viene distribuito come applicazione Laravel gestita dalla radice, in cui i file del core del CMS risiedono direttamente nella radice dell'installazione accanto ai file applicativi di proprietà dell'utente. Quel modello rende fragili gli aggiornamenti, perché il codice di prodotto del CMS e il codice di progetto specifico dell'installazione condividono lo stesso file system di primo livello.

Quando gli aggiornamenti del CMS vengono applicati sostituendo o copiando i file gestiti dalla radice, non è garantito che i file del core rimossi a monte scompaiano dalle installazioni a valle. Un file del core rimosso ma rimasto obsoleto può restare nella radice dell'installazione, continuare a essere autocaricato o renderizzato da Laravel e sovrascrivere silenziosamente il comportamento più recente distribuito. Questa è esattamente la classe di problemi confermata di recente da un file Blade obsoleto nella radice di un'installazione a valle.

L'architettura attuale mantiene inoltre gli aggiornamenti del CMS strettamente accoppiati allo stato di Git e alla sincronizzazione dei file sull'intera radice. Ciò rende più difficile ragionare sui confini di proprietà, preservare in sicurezza le personalizzazioni specifiche dell'installazione e rendere gli aggiornamenti prevedibili sulle installazioni esistenti.

L'architettura obiettivo è un pacchetto Laravel gestito con Composer:

• Nome del pacchetto: fklavyenet/webblocks-cms
• Percorso di installazione: vendor/fklavyenet/webblocks-cms
• Fonte di verità canonica del pacchetto installato: vendor/fklavyenet/webblocks-cms

Nel modello obiettivo, il codice del core del CMS viene installato e aggiornato come un normale pacchetto Composer anziché essere copiato nella radice del progetto Laravel di proprietà dell'utente.

Questo significa che:

• il codice sorgente PHP del CMS appartiene a src/ del pacchetto
• le risorse del pacchetto Laravel restano in config/, database/, resources/, routes/, public/ e stubs/ a livello di pacchetto
• src/ non è la destinazione di ogni file del pacchetto
• la radice Laravel di proprietà dell'utente dovrebbe possedere app/, config/, database/, public/site/, resources/, routes/, storage/ e composer.json

System Update deve allinearsi a questa disposizione del pacchetto Composer. Nei consumatori nativi del pacchetto installato, l'updater applica gli artefatti di release radicati nel pacchetto a vendor/fklavyenet/webblocks-cms; non deve mantenere packages/webblocks-cms come seconda copia di runtime attiva e aggiornata. Un albero packages/webblocks-cms appartiene soltanto ai checkout di sviluppo mantenuti dai sorgenti o a residui legacy della transizione.

Quando un'installazione vendor Composer legacy ha la forma di un repository, System Update normalizza vendor/fklavyenet/webblocks-cms alla radice piatta del pacchetto. Dopo la normalizzazione, src/, docs/, routes/, resources/, database/, public/, config/ e stubs/ risiedono direttamente sotto vendor/fklavyenet/webblocks-cms; i residui della radice del repository come artisan, app/, bootstrap/, packages/, plugins/ e tests/ vengono rimossi dalla sostituzione della radice del pacchetto.

project/ può rimanere temporaneamente come livello di compatibilità durante la transizione, ma non dovrebbe restare il modello di personalizzazione obbligatorio a lungo termine per il comportamento specifico dell'installazione.

La direzione prevista per il progetto iniziale è uno starter Laravel separato, come fklavyenet/webblocks-cms-starter, in cui la radice del progetto di proprietà dell'utente compone il pacchetto CMS invece di incorporare direttamente tutti i file del core del CMS.

La prontezza del pacchetto per i consumatori è ormai avviata, ma è volutamente parziale ed esplicita:

• i consumatori con una nuova installazione Laravel possono installare il pacchetto ed eseguire webblocks:install
• il pacchetto utilizza un percorso di migrazione mirato per le installazioni pulite dei consumatori, invece di ripercorrere l'intera catena storica di migrazioni della radice
• le migrazioni del pacchetto del repository di manutenzione restano disabilitate da guardie e inerti per impostazione predefinita
• App\Models\User resta il confine temporaneo di autenticazione del consumatore nella v1.32.8
• l'installer del pacchetto applica automaticamente una patch a App\Models\User con un trait del pacchetto e scrive prima un backup con marca temporale
• login, logout, avviso di installazione, protezione dell'area di amministrazione, home pubblica, viste e asset di proprietà del pacchetto sono ora sufficienti per il primo percorso pulito del consumatore
• questo non è ancora un repository starter separato e non rimuove ancora il confine User di proprietà dell'applicazione

L'albero reale dell'app consumatrice Composer può essere minimale mentre il runtime del CMS viene caricato da vendor/fklavyenet/webblocks-cms. Il repository di manutenzione rispecchia ora più fedelmente quel confine: la app/ della radice non conserva più per impostazione predefinita i wrapper corrispondenti a quelli del pacchetto.

Categorie di wrapper rimosse:

• comandi di console corrispondenti a quelli del pacchetto, tranne ProjectInitCommand, di proprietà dell'host
• controller di amministrazione e pubblici del CMS e middleware corrispondenti a quelli del pacchetto le cui rotte ora puntano a classi del pacchetto, tranne il middleware di redirect all'installazione della shell di manutenzione
• form request di amministrazione e pubblici corrispondenti a quelli del pacchetto
• mailable corrispondenti a quelli del pacchetto
• modelli del CMS corrispondenti a quelli del pacchetto
• classi di supporto corrispondenti a quelle del pacchetto nei domini di blocchi, media, pagine, siti, sistema, aggiornamenti, ricerca, visitatori e trasferimento/promozione operativi

Elementi volutamente ancora di proprietà della radice o rinviati:

• app/Models/User.php, il Controller.php di base e i service provider restano file della shell Laravel di proprietà dell'host.
• i file di autenticazione, profilo e installazione, incluso il middleware di redirect all'installazione, restano di proprietà dell'host finché il confine starter/installazione non verrà deliberatamente riprogettato.
• autenticazione, profilo, installazione e livello di progetto restano confini dell'host o della transizione.
• gli shim legacy per gli asset Asset, AssetFolder, BlockAsset e App\Support\Assets\... sono stati rimossi; i modelli media e le classi di supporto del pacchetto sono ora la superficie autorevole di runtime e di test.
• App\Support\WebBlocks è stato rimosso; la configurazione, le viste e i test della radice usano ora WebBlocks\Cms\Support\WebBlocks come fonte dell'identità e della versione del prodotto.
• le directory vuote di app/ nella radice corrispondenti a quelle del pacchetto vengono rimosse anziché mantenute come marcatori di transizione.
• le migrazioni della radice, gli override di configurazione, il public/cms di runtime, i wrapper di compatibilità Blade della radice e i wrapper dei seeder della radice restano fuori da questa pulizia.

La pulizia migliora la transizione al pacchetto e la prontezza dello starter, perché il repository di manutenzione verifica ora la stessa ipotesi di app minimale di un nuovo consumatore del pacchetto. Tuttavia non rende il repository completamente pronto come starter: installazione/autenticazione, User, l'autorità delle migrazioni della radice, l'autorità operativa di aggiornamento/installazione della radice e i percorsi di compatibilità degli asset di runtime della radice restano gli ostacoli finali.

Il flusso di aggiornamento a lungo termine dovrebbe essere gestito da Composer e dal pacchetto e indipendente da Git.

L'architettura di aggiornamento obiettivo è:

• nessuna copia di file del core del CMS sull'intera radice
• core del CMS installato e aggiornato tramite pacchetti Composer
• passi controllati di aggiornamento del runtime dopo l'aggiornamento del pacchetto, comprese le migrazioni
• svuotamento della cache dove necessario
• riparazione esplicita del catalogo come flusso di manutenzione separato dell'operatore quando serve
• pubblicazione o sincronizzazione controllata degli asset solo quando è realmente necessario

Questo mantiene i file della radice di proprietà dell'installazione separati dai file del core del CMS di proprietà del pacchetto e impedisce che i file del core del CMS rimossi permangano a tempo indeterminato nelle installazioni a valle solo perché un tempo esistevano nella radice.

Il pacchetto Composer e il repository di manutenzione sono consumatori di asset statici, non host di una catena di build frontend. WebBlocks CMS non deve distribuire né richiedere Vite, il plugin Vite di Laravel, Tailwind, npm, Node, file di lock dei pacchetti, public/build, public/hot o hook di runtime @vite per gli asset di proprietà del CMS.

Gli asset di proprietà del CMS appartengono a public/cms nella radice per il runtime di manutenzione e a packages/webblocks-cms/public/cms del pacchetto per gli artefatti di release. WebBlocks UI resta un progetto UI a monte consumato tramite asset pubblicati e fissati a una versione, e WebBlocks UI Manager resta il plugin operatore di prima parte per i flussi di pubblicazione di release e CDN. Non spostate la compilazione dei sorgenti di WebBlocks UI, gli script di build npm, la generazione della dist o le ipotesi sul file hot nel core del CMS o nel suo pacchetto di release.

Percorsi CMS obiettivo di proprietà del pacchetto:

• packages/webblocks-cms/src/ durante la fase di transizione interna al repository
• successivamente vendor/fklavyenet/webblocks-cms/src/ negli ambienti installati
• config/ del pacchetto
• database/ del pacchetto
• resources/ del pacchetto
• routes/ del pacchetto
• public/ del pacchetto
• stubs/ del pacchetto

Percorsi obiettivo della radice di progetto di proprietà dell'utente:

• app/
• config/
• database/
• public/site/
• resources/
• routes/
• storage/
• composer.json

Questa suddivisione lascia la proprietà dell'applicazione Laravel all'installazione, mentre la proprietà del prodotto CMS passa al pacchetto.

Le installazioni del CMS orientate al pacchetto devono preservare i confini dell'applicazione host quando il CMS è installato accanto a un altro prodotto Laravel. Il CMS dovrebbe evitare collisioni di rotte, configurazione, viste e tabelle con l'app host e non deve presupporre che la rotta /admin dell'app host appartenga al CMS.

Il prefisso canonico di amministrazione del CMS è /webadmin, con un prefisso configurabile che resta la direzione obiettivo per una maggiore flessibilità di coesistenza futura. Il login di proprietà dell'host e le decisioni di autorizzazione di proprietà del CMS sono documentati in Coexistence. Gli asset statici del CMS restano sotto public/cms e vengono serviti da /cms/....

Quando le rotte di autenticazione del CMS di proprietà del pacchetto sono attive, /webadmin/login fa parte del confine del pacchetto. La sua superficie Blade deve restare sotto il namespace di viste webblocks-cms::, utilizzare la shell di autenticazione guest di WebBlocks UI, caricare il CSS/JS fissato di WebBlocks UI insieme a /cms/css/guest.css e risolvere gli asset di brand e logo del prodotto da /cms/brand. Gli asset di brand del prodotto CMS devono fornire varianti normale, per superficie scura, su accento/inversa e ad alto contrasto per favicon e scheda del browser, così che il contrasto dell'autenticazione e della shell di prodotto sia risolto con asset espliciti anziché con filtri CSS.

I prefissi delle rotte di amministrazione non devono riutilizzare segmenti fisici di directory di asset pubblici. Il prefisso di amministrazione ritirato /cms collideva con la directory di asset attiva public/cms, perché try_files di Nginx può risolvere /cms/ come directory prima che Laravel riceva la rotta. Per questo l'attuale architettura a pacchetto mantiene /webadmin/... per l'amministrazione del CMS e per le rotte di login del pacchetto, riserva /cms/... ai soli asset statici e vieta alias /cms, redirect /cms e rotte /admin di proprietà del CMS ripristinate. Il vecchio passaggio di consegne public/cms/index.php non fa parte del confine del pacchetto e deve restare assente sia dagli asset pubblici della radice sia da quelli del pacchetto.

Introducete il piano dell'architettura a pacchetto e create uno scheletro di pacchetto interno al repository senza spostare ancora il codice di runtime. Il comportamento dell'app radice resta invariato.

Aggiungete il service provider del pacchetto e il collegamento Composer con percorso locale, così che il pacchetto esista come una vera unità installabile all'interno del repository. Mantenete la logica di boot volutamente minima ed evitate di modificare il comportamento a runtime.

Affinate il service provider del pacchetto affinché definisca il contratto di bootstrap per le future risorse di proprietà del pacchetto, senza renderle ancora autorevoli.

In questa fase il provider può preparare in sicurezza il caricamento protetto e la registrazione della pubblicazione per config/, routes/, resources/views/, database/migrations/, public/ e stubs/ del pacchetto, ma soltanto quando esistono file reali del pacchetto.

L'attuale comportamento a runtime della radice resta invariato perché lo scheletro del pacchetto contiene solo segnaposto. Finché i file di runtime non verranno effettivamente spostati nel pacchetto nelle fasi successive, l'applicazione Laravel della radice resta la fonte autorevole per rotte, viste, configurazione, migrazioni e asset pubblici attivi del CMS.

Il primo percorso di configurazione predefinita di proprietà del pacchetto è ormai avviato con config/webblocks-updates.php del pacchetto. Durante la transizione quel file del pacchetto fornisce i valori predefiniti di proprietà del CMS, mentre il config/webblocks-updates.php esistente nella radice resta al suo posto come override a livello di installazione e file di configurazione applicativa retrocompatibile.

Gli attuali file di config/ nella radice ricadono in due gruppi di transizione.

Candidati a valori predefiniti del prodotto CMS:

• webblocks-cms.php
• cms.php
• contact.php
• demo_media.php
• webblocks-updates.php

Configurazione di proprietà dell'app Laravel o dell'installazione che dovrebbe restare della radice:

• app.php
• auth.php
• cache.php
• database.php
• filesystems.php
• logging.php
• mail.php
• queue.php
• services.php
• session.php

L'attuale regola di transizione a basso rischio consiste nello spostare la configurazione predefinita di proprietà del CMS soltanto quando ciò preserva un comportamento di prodotto stabile e una chiara semantica di override da parte dell'installazione. L'insieme dei valori predefiniti di proprietà del pacchetto comprende ora webblocks-cms.php, cms.php, contact.php, demo_media.php e webblocks-updates.php. I file di configurazione della radice per il comportamento esistente del CMS restano al loro posto durante la transizione come override a livello di installazione e punti di ingresso della configurazione applicativa retrocompatibili. webblocks-cms.php per ora è esclusivo del pacchetto e possiede i controlli di transizione: le rotte diagnostiche, le rotte pubbliche di stato, le rotte di stato dell'area di amministrazione e il caricamento delle migrazioni del pacchetto restano disabilitati per impostazione predefinita, mentre il caricamento delle rotte di amministrazione del pacchetto è abilitato affinché le rotte di amministrazione di proprietà del pacchetto possano diventare autorevoli.

Iniziate a spostare il codice sorgente PHP di proprietà del CMS in src/ del pacchetto in piccole porzioni revisionabili, aggiornando i namespace e il bootstrap del service provider soltanto man mano che ciascuna area spostata è pronta.

Il bootstrap di console del pacchetto è ora dimostrato anche dal comando diagnostico di sola lettura webblocks:package-status. Quel comando è di proprietà del pacchetto, viene registrato solo in contesti di console e segnala la presenza del bootstrap del pacchetto senza modificare file, stato del database, cache, configurazione o stato di aggiornamento.

Il primo spostamento di codice sorgente PHP dovrebbe seguire criteri altrettanto conservativi: di proprietà del CMS, di piccole dimensioni, facile da comprendere, senza dipendenze da database o Eloquent, senza dipendenze da controller o request e con aggiornamenti di riferimenti circoscritti. La prima classe spostata è SearchTextNormalizer, un helper puro per il testo di ricerca ora di proprietà di src/Support/Search/ del pacchetto.

Attuale confine del supporto alla ricerca:

• ora di proprietà del pacchetto: SearchTextNormalizer, PublicSearchRebuildResult, PublicSearchIndexer, PublicSearchQuery, PublicSearchSchema, SearchablePageResolver, BlockSearchTextExtractorRegistry e ReindexesPublicSearch
• al momento nessuna classe di supporto di Search deve restare di proprietà della root per motivi specifici del progetto; lo shim root App\Support\Search\ReindexesPublicSearch è stato rimosso

Confine attuale dell'audit del Support non legato a Search:

• in questo passo dell'audit non è stato spostato nessun ulteriore helper di Support non legato a Search, perché nessuno dei candidati esaminati soddisfaceva gli attuali criteri a basso rischio per il passaggio al pacchetto
• MediaKindResolver è piccolo e deterministico, ma attualmente dipende dalle costanti di App\Models\Media ed è referenziato da un percorso di controller, quindi non è ancora abbastanza indipendente per questa fase
• DatabaseExecutionStrategyResolver resta per ora di proprietà della root, perché incide direttamente sulla strategia di esecuzione di dump o ripristino del database, sull'ispezione dell'ambiente e sulla sicurezza a runtime di backup o ripristino
• SiteHandle resta per ora di proprietà della root, perché è utilizzato da modelli, request e flussi di trasferimento o clonazione dei siti, quindi spostarlo ora attraverserebbe troppo presto i confini di routing, portabilità e persistenza
• SiteDomainNormalizer resta per ora di proprietà della root, perché è ancora utilizzato da modelli, request, risoluzione delle rotte e migrazioni, a conferma della precedente valutazione del rischio

Confine del supporto Contact:

• ora di proprietà del pacchetto: ContactMessageNotificationResult
• per ora di proprietà della root: ContactMessageNotifier, perché gestisce ancora le chiamate di trasporto della posta, l'interazione con il modello dei contatti e la risoluzione dei destinatari basata sulla configurazione
• ContactMessageNotificationResult è stato spostato in sicurezza perché è un piccolo oggetto risultato immutabile, senza accoppiamento a modelli, database, request, configurazione, posta, migrazioni o payload serializzati, e richiedeva solo l'aggiornamento di un riferimento circoscritto nel notifier

Confine del supporto per i tipi di blocco:

• ora di proprietà del pacchetto: BlockTypeContract
• per ora di proprietà della root: BlockTypeContractRegistry, perché dipende ancora dai modelli dei blocchi, dalle definizioni di sincronizzazione del catalogo, dal comportamento del registro delle traduzioni, dall'ispezione dei percorsi delle risorse e dai flussi di audit o amministrazione della root che utilizzano quei contratti risolti
• BlockTypeContract è stato spostato in sicurezza perché è un piccolo DTO di contratto con stato impostato solo nel costruttore, oltre a una serializzazione in array deterministica, e senza accoppiamento a modelli, database, request, configurazione, effetti collaterali di comandi, migrazioni o payload serializzati

Confine del markup del layout di pagina:

• per ora di proprietà della root: LayoutMarkup
• LayoutMarkup non è stato spostato in questo passo perché, benché sia piccolo e senza stato, è utilizzato direttamente dai form request del layout di pagina, dalla logica del gestore dei layout di pagina, dalla risoluzione del wrapper degli slot pubblici e da un form Blade di amministrazione; spostarlo ora attraverserebbe i confini di validazione delle request e di rendering pubblico all'interno dell'area più ampia Pages o PublicRendering, che resta intenzionalmente di proprietà della root

Confine del supporto di formattazione:

• ora di proprietà del pacchetto: InlineRichTextRenderer
• per ora di proprietà della root: SafeRichTextRenderer, perché gestisce ancora il contratto di sanitizzazione HTML più ricco, il comportamento dei tag consentiti, le regole di parsing del DOM e la semantica di rendering pubblico del rich text
• InlineRichTextRenderer è stato spostato in sicurezza perché è un piccolo formattatore deterministico, senza accoppiamento a modelli, database, request, configurazione, migrazioni o payload serializzati, e richiedeva solo l'aggiornamento di un riferimento circoscritto in Blade e negli unit test

Mappa di migrazione dei sorgenti di Support:

• Search: di proprietà del pacchetto per l'attuale supporto a runtime, incluso il trait di reindicizzazione usato dai modelli del pacchetto. Gli shim root App\Support\Search\... non devono essere ripristinati.
• Formatting: candidato dopo l'isolamento delle dipendenze. InlineRichTextRenderer è ora di proprietà del pacchetto come helper di formattazione a basso rischio, mentre SafeRichTextRenderer resta di proprietà della root perché definisce il comportamento di sanitizzazione a rischio più elevato.
• BlockTypes: candidato dopo l'isolamento delle dipendenze. BlockTypeContract è un piccolo value object, ma il namespace è ancorato a BlockTypeContractRegistry, alle rotte di amministrazione e a un comando di audit da console nella root.
• BlockTypes: candidato dopo l'isolamento delle dipendenze. BlockTypeContract è ora di proprietà del pacchetto come spostamento circoscritto di un value object, ma il namespace è ancora ancorato a BlockTypeContractRegistry, alle rotte di amministrazione e a un comando di audit da console nella root.
• Media and Assets: i modelli media e le classi di supporto di proprietà del pacchetto sono autoritativi per gli shim legacy degli asset ormai rimossi. Il lavoro rimanente sui media deve evitare di ripristinare i wrapper root Asset, AssetFolder, BlockAsset o App\Support\Assets\....
• Pages and PublicRendering: di proprietà della root fino a una fase di migrazione dedicata. Queste classi controllano la risoluzione delle rotte, la selezione del layout, gli asset di pagina, i wrapper degli slot, i presenter pubblici, la duplicazione o importazione delle pagine e il comportamento di rendering pubblico, con accoppiamento a modelli e request in tutto il percorso.
• Pages and PublicRendering: di proprietà della root fino a una fase di migrazione dedicata. LayoutMarkup è stato esaminato come possibile eccezione, ma resta di proprietà della root perché poggia ancora direttamente sulle request di layout di pagina, sulla risoluzione dei wrapper degli slot e sul rendering delle viste di amministrazione, anche se la sua logica è priva di stato.
• Blocks: di proprietà della root fino a una fase di migrazione dedicata. Quest'area gestisce le scritture del payload dei blocchi, la persistenza delle traduzioni, l'eliminazione dei blocchi, la sincronizzazione del catalogo, l'estrazione di HTML attendibile e i registri pubblici con ambito di request, che poggiano direttamente sulla persistenza dei blocchi e sui contratti del renderer.
• SharedSlots and Revisions: di proprietà della root fino a una fase di migrazione dedicata. Queste classi dipendono da alberi di blocchi, tabelle delle revisioni, controlli di schema, righe di traduzione e semantica di ripristino o snapshot.
• Sites, Sites\\ExportImport e SitePromotion: di proprietà della root fino a una fase di migrazione dedicata. Queste aree sono strettamente accoppiate a modelli, routing, portabilità, archivi, payload serializzati di trasferimento, flussi di clonazione o eliminazione, backup di sicurezza della promozione e risoluzione dei siti pubblici.
• System and System\\Updates: di proprietà della root fino a una fase di migrazione dedicata. Queste classi gestiscono la persistenza delle impostazioni, lo stato della versione installata, il backup o ripristino, la validazione SQL, il flusso di download o estrazione degli aggiornamenti e la strategia di esecuzione del database.
• Install and ProjectLayer: da non spostare ancora. Queste classi toccano il flusso dell'installer, le scritture su .env, il caricamento di rotte o provider, i controlli dello stato di installazione e i confini di personalizzazione della root di progetto.
• Navigation, Locales, Users, Visitors, Contact and Icons: candidati dopo l'isolamento delle dipendenze. Ogni gruppo contiene alcuni helper o oggetti risultato più piccoli, ma le implementazioni attuali dipendono ancora da modelli, autenticazione, posta, ispezione dello schema, chiamate HTTP o comportamento a runtime basato sulle impostazioni.
• Navigation, Locales, Users, Visitors, Contact and Icons: candidati dopo l'isolamento delle dipendenze. ContactMessageNotificationResult è ora di proprietà del pacchetto come spostamento circoscritto di un value object, mentre i gruppi rimanenti dipendono ancora da modelli, autenticazione, posta, ispezione dello schema, chiamate HTTP o comportamento a runtime basato sulle impostazioni.
• Admin, Audit and Database: candidati dopo l'isolamento delle dipendenze. AdminPagination, CurrentActorResolver e DestructiveDatabaseCommandGuard sono piccoli, ma ciascuno dipende ancora dalle impostazioni della root, dall'autenticazione o dagli hook di sicurezza dell'applicazione.
• WebBlocks: WebBlocks\Cms\Support\WebBlocks, di proprietà del pacchetto, è ora la fonte dell'identità e della versione del prodotto sia per i consumatori del pacchetto sia per la root del repository di manutenzione.

Nota sul checkpoint dei sorgenti della fase 2:

• i primi spostamenti a basso rischio di helper e value object si sono conclusi correttamente fino a v1.31.60
• l'ambiente di sviluppo locale collegato al pacchetto è stato aggiornato correttamente dopo v1.31.60, confermando che il checkpoint resta compatibile con il flusso di lavoro locale mantenuto
• gli spostamenti opportunistici di sorgenti PHP a basso rischio sono ora intenzionalmente sospesi
• non continuate a spostare classi con forte componente di runtime senza un piano di fase dedicato e un audit delle dipendenze

Blocchi attuali per i gruppi a rischio più elevato:

• accoppiamento diretto con App\Models\... o con query Eloquent in Search, Pages, Blocks, Sites, Navigation, Locales, Icons, Visitors e System
• accoppiamento a request, rotte, controller o viste in Admin, Pages, PublicRendering, Formatting e in alcuni helper di BlockTypes
• controlli di schema, di forma delle migrazioni o di esistenza delle tabelle in Search, SharedSlots, Revisions, Visitors, Install e System
• accoppiamento a configurazione, env, HTTP, posta, filesystem, processi, backup, aggiornamenti e runtime locale in Contact, Icons, Install, System e Updates
• accoppiamento a payload serializzati di archivio o trasferimento in Sites\\ExportImport, SitePromotion, importazione delle pagine e helper di compatibilità per gli asset legacy

Spostate nelle cartelle di risorse Laravel del pacchetto la configurazione, le rotte, le viste, le migrazioni, i seeder, gli asset pubblici e gli stub chiaramente di proprietà del pacchetto. Introducete il comportamento di caricamento e pubblicazione del pacchetto in modo incrementale, non tutto insieme.

L'attuale porzione di seeder della fase 3 copre ora il confine dei seeder di catalogo di proprietà del pacchetto, oltre al relativo aggregatore di proprietà del pacchetto:

• ora di proprietà del pacchetto: CoreCatalogSeeder, IconCatalogSeeder, PageTypeSeeder, LayoutTypeSeeder, SlotTypeSeeder in packages/webblocks-cms/database/seeders/
• gli entrypoint di compatibilità della root restano in database/seeders/, così le installazioni esistenti, i test e gli attuali entrypoint di runtime o di aggiornamento possono continuare a chiamare Database\Seeders\...
• il CoreCatalogSeeder di proprietà del pacchetto resta solo uno spostamento di proprietà: continua a delegare a PageLayoutSeeder e BlockTypeSeeder, di proprietà della root, e l'attuale DatabaseSeeder root insieme agli entrypoint di aggiornamento continua a richiamare il wrapper di compatibilità della root
• restano per ora di proprietà della root: PageLayoutSeeder, BlockTypeSeeder, DatabaseSeeder e i comandi post-installazione attivi di System Update
• in questa fase la proprietà dei seeder da parte del pacchetto riguarda solo la migrazione di namespace e confini, non un cambiamento dell'attuale autorità di aggiornamento della root

Il focus successivo della transizione dopo v1.31.60 è la proprietà delle risorse del pacchetto, non altri spostamenti opportunistici di helper.

Il checkpoint v1.31.62 trasforma il confine delle risorse del pacchetto in un pilota più esplicito e verificabile, senza trasferire ancora la proprietà attiva a runtime.

• le directory routes/, resources/views/, database/migrations/, public/ e stubs/ del pacchetto esistono ora come directory di confine del pacchetto esplicitamente riservate, con file marcatori che documentano l'intento di proprietà futura
• i valori predefiniti di configurazione del pacchetto restano di proprietà del CMS nella cartella config/ del pacchetto
• i file di configurazione corrispondenti nella root restano il livello di override a livello di installazione e gli entrypoint di configurazione dell'applicazione retrocompatibili
• il service provider del pacchetto mantiene la pubblicazione del pacchetto esplicita e contrassegnata da tag, ma la pubblicazione resta inerte a meno che uno sviluppatore non esegua intenzionalmente vendor:publish
• il namespace delle viste del pacchetto webblocks-cms è ora registrato come pilota sicuro del confine del pacchetto, senza modificare l'attuale risoluzione delle viste pubbliche o di amministrazione della root
• rotte, viste, migrazioni, asset pubblici e stub del pacchetto non costituiscono ancora una proprietà autoritativa e attiva a runtime in questa fase
• webblocks:package-status ora riporta, in modo strettamente di sola lettura, lo stato delle risorse del pacchetto: riservate rispetto a popolate

Questo pilota non sposta rotte, viste, migrazioni o asset pubblici attivi della root, né controller, request, modelli, servizi o il comportamento di System Update.

Il checkpoint v1.31.63 trasforma il namespace delle viste del pacchetto, finora riservato, in un confine diagnostico concreto e verificabile di proprietà del pacchetto, senza modificare la proprietà attiva a runtime.

• il file resources/views/diagnostics/package-status.blade.php del pacchetto esiste ora come vera vista Blade diagnostica interna di proprietà del pacchetto
• la vista diagnostica viene renderizzata solo tramite il namespace webblocks-cms:: e non è esposta da alcuna rotta pubblica o di amministrazione
• webblocks:package-status può ora eseguire facoltativamente --view-check per renderizzare quella vista diagnostica in modo strettamente di sola lettura e confermare che il namespace delle viste del pacchetto si risolve correttamente
• l'output predefinito di webblocks:package-status resta leggero e di sola lettura, mentre il controllo facoltativo della vista non esegue comunque scritture di file, di cache, di configurazione, di database né modifiche allo stato di installazione
• le viste pubbliche e di amministrazione attive della root restano autoritative e in questa fase non cambia alcun percorso di vista della root né la proprietà delle rotte a runtime

Questo pilota dimostra il caricamento del namespace delle viste del pacchetto con un file Blade reale di proprietà del pacchetto, evitando intenzionalmente qualsiasi spostamento delle viste pubbliche o di amministrazione attive della root.

Il checkpoint v1.31.64 trasforma il confine delle rotte del pacchetto, finora riservato, in un pilota di rotte diagnostiche concreto e verificabile, senza modificare la proprietà attiva delle rotte.

• il file routes/diagnostics.php del pacchetto esiste ora come vero file di rotte diagnostiche di proprietà del pacchetto, per futuri diagnostici interni al pacchetto
• il service provider del pacchetto mantiene il caricamento delle rotte diagnostiche del pacchetto esplicitamente protetto da webblocks-cms.diagnostics.load_routes, così le rotte diagnostiche del pacchetto non vengono caricate nel runtime normale per impostazione predefinita
• webblocks:package-status ora riporta la presenza del confine delle rotte del pacchetto, lo stato del file di rotte del pacchetto, l'esistenza del file di rotte diagnostiche atteso, lo stato protetto del caricamento delle rotte e se la rotta diagnostica è attualmente caricata
• le rotte pubbliche e di amministrazione attive della root restano autoritative e in questa fase nessun file di rotte pubbliche o di amministrazione della root è stato spostato o modificato

Questo pilota dimostra il confine delle rotte del pacchetto con un file di rotte diagnostiche reale di proprietà del pacchetto, evitando intenzionalmente qualsiasi migrazione della proprietà delle rotte pubbliche o di amministrazione attive.

Il checkpoint v1.31.65 completa i restanti pilota del confine del pacchetto non legati al runtime per migrazioni, asset pubblici, stub e la destinazione del flusso di aggiornamento gestito da Composer, senza spostare la proprietà attiva a runtime.

• le cartelle del pacchetto database/migrations/, public/ e stubs/ conservano ora una documentazione più chiara dei marcatori di confine riservato per i loro futuri ruoli di proprietà del pacchetto
• il caricamento delle migrazioni del pacchetto è ora esplicitamente disattivato tramite la guardia webblocks-cms.boundaries.load_migrations, quindi le migrazioni del pacchetto restano inerti a meno che una successiva fase di runtime mirata non le colleghi intenzionalmente
• la pubblicazione degli asset pubblici e degli stub del pacchetto resta esplicita e contrassegnata con tag di pacchetto; ora pubblica il primo marcatore di asset di proprietà del pacchetto e gli stub iniziali senza sostituire gli asset di runtime root né l'installer attuale
• webblocks:package-status riporta ora lo stato del confine delle migrazioni, del confine degli asset pubblici e del confine degli stub, la nota sull'obiettivo di aggiornamento gestito da Composer e la regola tuttora valida secondo cui il runtime root resta autorevole
• il comportamento attuale di Composer nella root, il caricamento del runtime root e il comportamento di System Update restano invariati in questo checkpoint

Questo checkpoint completa la fase pilota dei confini del pacchetto. Il repository dispone ora di confini di pacchetto concreti e verificabili per rotte, viste, migrazioni, asset pubblici, stub e intento di aggiornamento gestito da Composer, mentre la proprietà del runtime attivo resta ancora nell'applicazione root.

• scegliete un'unica porzione di runtime ristretta, chiaramente di proprietà del pacchetto e con un rischio abbastanza basso da poter essere spostata da un capo all'altro
• spostatela solo quando le regole di proprietà di rotte, viste, migrazioni, asset o runtime sono esplicite per quella porzione
• verificate la compatibilità con le versioni precedenti e le aspettative di installazione prima che qualsiasi autorità di runtime attivo passi dalla root al pacchetto
• mantenete invariato il comportamento di System Update finché una successiva fase dedicata al flusso di aggiornamento non lo riprogetti intenzionalmente

La release v1.32.0 è il primo checkpoint con una porzione di runtime reale di proprietà del pacchetto. Avvia il lavoro sul runtime di proprietà del pacchetto con tre porzioni protette deliberatamente piccole, che dimostrano la proprietà del runtime da parte del pacchetto senza sostituire il runtime attuale del CMS.

Fase 1: porzione di runtime di diagnostica del pacchetto, protetta

• il file routes/diagnostics.php del pacchetto punta ora a un controller di proprietà del pacchetto in packages/webblocks-cms/src/Http/Controllers/Diagnostics/PackageDiagnosticsController.php
• quel controller renderizza la vista di diagnostica esistente del pacchetto webblocks-cms::diagnostics.package-status
• la rotta di diagnostica resta comunque disattivata per impostazione predefinita dietro webblocks-cms.diagnostics.load_routes
• si tratta intenzionalmente solo di un percorso interno riservato del pacchetto e non sostituisce alcuna rotta di runtime amministrativa o pubblica della root

Fase 2A: prima porzione mirata di amministrazione del pacchetto

• il file routes/admin.php del pacchetto ha introdotto originariamente una piccola porzione di stato del runtime amministrativo di proprietà del pacchetto: admin.webblocks-cms.runtime-status, ora montata su /webadmin/_webblocks-cms/runtime-status
• quella rotta di stato utilizza un controller di proprietà del pacchetto e una vista Blade di proprietà del pacchetto in packages/webblocks-cms/resources/views/admin/runtime-status.blade.php
• il caricamento delle rotte amministrative del pacchetto è ora abilitato per impostazione predefinita e l'albero attivo delle rotte amministrative del CMS viene caricato dal file routes/admin.php del pacchetto
• la rotta riservata di stato amministrativo resta a sua volta disattivata per impostazione predefinita dietro webblocks-cms.admin.load_status_route
• le rotte amministrative del pacchetto mantengono, ove opportuno, i normali requisiti di middleware per installazione, autenticazione, accesso amministrativo e accesso di sistema del super admin
• la proprietà del runtime amministrativo attivo è ora del pacchetto per Pages, Blocks, Media, Shared Slots, Navigation, Block Types, Page Layouts, Sites, Site Domains, Site Variables e Locales, mentre Users, System, installazione/aggiornamento, backup/ripristino, esportazione/importazione, promozione, autenticazione/profilo, migrazioni e asset di runtime root restano di proprietà della root

Fase 2B: prima porzione pubblica mirata del pacchetto

• il file routes/public.php del pacchetto ha introdotto originariamente una piccola porzione di stato del runtime pubblico di proprietà del pacchetto: webblocks-cms.public.runtime-status su /_webblocks-cms/runtime-status
• quella rotta utilizza un controller di proprietà del pacchetto e una vista Blade di proprietà del pacchetto in packages/webblocks-cms/resources/views/public/runtime-status.blade.php
• il caricamento delle rotte pubbliche del pacchetto è ora abilitato per impostazione predefinita e l'albero attivo delle rotte pubbliche del CMS viene caricato dal file routes/public.php del pacchetto
• i controller di ingresso pubblici di proprietà del pacchetto gestiscono ora home, home localizzata, ricerca, ricerca localizzata, ricerca JSON, visualizzazione della pagina, visualizzazione della pagina localizzata, invio dei messaggi di contatto, sincronizzazione del consenso privacy e gli endpoint interni di dominio admin-api.*
• le viste di ingresso pubbliche di proprietà del pacchetto coprono ora i template di ingresso di pagina e ricerca tramite webblocks-cms::public.pages.show e webblocks-cms::public.search.show
• la rotta riservata di stato pubblico del pacchetto resta a sua volta disattivata per impostazione predefinita dietro webblocks-cms.public.load_status_route
• l'autorità di runtime sugli asset pubblici e i confini di installazione/aggiornamento restano di proprietà della root al di fuori delle porzioni pubbliche di rotta, modello, supporto e vista spostate esplicitamente nel pacchetto

Perché queste porzioni restano parzialmente protette

• il runtime root resta autorevole per le installazioni al di fuori delle porzioni spostate intenzionalmente nel pacchetto
• i percorsi riservati del pacchetto evitano conflitti di nome di rotta e di percorso con il runtime amministrativo e pubblico esistente
• le rotte di stato protette separatamente consentono di testare il bootstrap del pacchetto, il caricamento delle rotte, il caricamento delle viste, il comportamento dei middleware e la segnalazione dello stato senza forzare quei percorsi di diagnostica riservati nel runtime normale
• l'autorità di runtime spostata è ancora intenzionalmente parziale, così i gruppi ad alto rischio come i modelli, la maggior parte delle classi di implementazione amministrativa, i livelli di supporto più ampi, le migrazioni, gli asset e il comportamento di System Update evitano una proprietà prematura da parte del pacchetto

• continuate a ridurre il caricamento di compatibilità delle rotte nella root solo dopo che le restanti implementazioni amministrative e pubbliche dietro i file di rotte del pacchetto sono state spostate o intenzionalmente lasciate alla root
• mantenete le rotte riservate di diagnostica e di stato del runtime esplicitamente protette anche mentre gli alberi normali delle rotte amministrative e pubbliche del CMS sono autorevoli dal pacchetto
• preservate nomi di rotta, percorsi, middleware e comportamento dei redirect mentre l'autorità delle rotte del pacchetto resta in anticipo rispetto a un'estrazione più profonda del runtime
• considerate la futura pulizia delle rotte come una fase di riduzione della compatibilità, non come la prova che il CMS sia già pronto come pacchetto per i consumatori

• spostate viste reali di proprietà del pacchetto solo in fasi successive mirate, raggruppate per ambito di runtime: per esempio prima la diagnostica di proprietà del pacchetto, poi una proprietà delle viste amministrative o pubbliche attentamente verificata
• mantenete allineate la proprietà delle rotte e quella delle viste, così che una vista spostata in futuro venga introdotta solo quando il percorso di runtime proprietario è intenzionalmente gestito dal pacchetto
• preservate regole chiare di override in installazione e di autorità della root finché ogni fase di proprietà di rotte o viste non è progettata e verificata esplicitamente

• La cartella config/ del pacchetto dovrebbe continuare a definire i valori predefiniti di proprietà del CMS.
• Il config/ della root resta il livello di override di proprietà dell'installazione durante la transizione.
• Un file di configurazione del pacchetto non dovrebbe diventare autorevole per il comportamento a runtime finché la logica degli override e il cablaggio del bootstrap non sono espliciti e stabili.

• Le migrazioni del pacchetto dovrebbero restare non autorevoli finché non esistono migrazioni reali di proprietà del pacchetto e la loro proprietà non viene spostata intenzionalmente.
• Quando inizia la proprietà delle migrazioni, preferite il caricamento dal pacchetto per i file di migrazione di proprietà del CMS e indicazioni di pubblicazione esplicite solo dove la personalizzazione locale dell'installazione è davvero necessaria.
• Non mescolate il lavoro sui confini delle migrazioni con refactoring di runtime non correlati.
• La cartella database/migrations/ della root resta il livello di compatibilità e di autorità per le installazioni mantenute da sorgente. Il percorso di aggiornamento mantenuto da sorgente richiede il segnale di autoload di Composer nella root del repository di manutenzione per WebBlocks\\Cms\\ => packages/webblocks-cms/src/; non basta che un'installazione consumer abbia una cartella packages/webblocks-cms. Gli aggiornamenti delle installazioni consumer del pacchetto devono usare migrazioni di aggiornamento esplicite di proprietà del pacchetto e non devono eseguire implicitamente le migrazioni dell'applicazione Laravel ospite.
• Le installazioni nuove consumer del pacchetto usano lo schema database/migrations/fresh di proprietà del pacchetto tramite webblocks:install. L'installer verifica preventivamente le tabelle CMS parziali prima dell'esecuzione di quello schema, si ferma con la diagnostica per impostazione predefinita e rinomina solo le tabelle parziali vuote quando l'operatore fornisce --repair-partial.
• PageLayoutSeeder e BlockTypeSeeder restano per ora di proprietà della root perché attraversano ancora il catalogo dei page layouts, la sincronizzazione dei block types e confini più ampi del runtime di Pages o Blocks. Anche DatabaseSeeder resta di proprietà della root come entrypoint attivo dell'installazione e come scrittore della versione installata.

• La proprietà delle rotte da parte del pacchetto è ora attiva per gli alberi di runtime amministrativo e pubblico del CMS tramite i file routes/admin.php e routes/public.php del pacchetto.
• Il file routes/web.php della root è ora ridotto a installazione, autenticazione, profilo e caricamento di compatibilità di quei file di rotte del CMS di proprietà del pacchetto.
• Gli spostamenti delle rotte devono continuare a preservare middleware, binding, nomi, percorsi, flussi modali, redirect e aspettative di installazione a valle.
• Le rotte di diagnostica, di stato del runtime amministrativo e di stato del runtime pubblico restano percorsi riservati protetti separatamente e non fanno parte della normale superficie di rotte del CMS sempre attiva.
• L'autorità sulle rotte non implica ancora la piena proprietà del runtime da parte del pacchetto, perché molti handler dietro quelle rotte dipendono ancora da modelli, codice di supporto, viste e asset della root.

• La cartella resources/views del pacchetto possiede ora la vista di diagnostica, le viste protette di stato del runtime amministrativo e pubblico, le viste amministrative del catalogo delle icone, lo shell del layout pubblico, gli shell pubblici di pagina e ricerca, il modale pubblico di ricerca e le viste di ingresso degli slot di proprietà del pacchetto.
• La cartella resources/views della root mantiene ora wrapper di compatibilità per le viste spostate di layout, pagina, slot e ingresso di ricerca pubblici, pur restando autorevole per la maggior parte delle schermate amministrative e per il più ampio albero di compatibilità del renderer pubblico dei blocchi, non ancora estratto del tutto.
• Gli spostamenti delle viste dovrebbero restare allineati al percorso di runtime proprietario, così che l'autorità delle rotte del pacchetto non si spinga troppo avanti rispetto al reale livello di viste e controller proprietario.
• Le viste della root restano la via di compatibilità per la maggior parte del rendering attivo del CMS al di fuori delle superfici webblocks-cms:: spostate intenzionalmente.

• La cartella public/ del pacchetto dovrebbe col tempo possedere gli asset pubblicabili di proprietà del CMS.
• Il lavoro di transizione dovrebbe distinguere gli asset del pacchetto di proprietà del CMS dagli override public/site/... di proprietà dell'installazione.
• La pubblicazione o sincronizzazione degli asset dovrebbe avvenire solo quando esistono asset reali del pacchetto e il flusso di aggiornamento definisce chiaramente quando la pubblicazione è necessaria.
• L'attuale intento di pubblicazione resta esplicito e contrassegnato con tag di pacchetto. public/cms/package-boundary.json è il primo asset pubblicabile di proprietà del pacchetto e può essere pubblicato tramite webblocks-cms-assets.
• La cartella public/cms/ del pacchetto contiene ora anche il CSS e il JS del layout pubblico usati dal layout pubblico spostato di proprietà del pacchetto, ma gli URL degli asset public/cms/... attuali della root restano autorevoli nel runtime attivo per compatibilità, mentre gli asset public/site/... di proprietà dell'installazione restano autorevoli per gli override per singolo sito.
• La cartella public/cms/ del pacchetto non deve contenere index.php; l'ingresso amministrativo del CMS è /webadmin, non un ponte di front controller dalla cartella degli asset statici.
• Il pinning della CDN di WebBlocks UI e la sorgente di sincronizzazione del manifest predefinito delle icone restano invariati in questa fase.

• La cartella stubs/ del pacchetto dovrebbe essere riservata a template riutilizzabili di file generati che appartengono al comportamento del prodotto CMS.
• Lo scaffolding specifico di un'installazione o di un progetto non dovrebbe confluire per impostazione predefinita negli stub del pacchetto CMS.
• Gli stub orientati all'avvio dei progetti risiedono ora in stubs/starter/ nel pacchetto, ma il comportamento attuale dell'installer e lo scaffolding del progetto root restano autorevoli finché un pacchetto starter dedicato non li adotta intenzionalmente.

• webblocks-cms-config è riservato alla pubblicazione, nella root dell'installazione, dei file di configurazione predefiniti del CMS di proprietà del pacchetto, quando uno sviluppatore ha intenzionalmente bisogno di quel flusso di lavoro.
• webblocks-cms-assets pubblica gli asset pubblici del CMS di proprietà del pacchetto nel percorso di compatibilità del runtime attivo, public/cms.
• webblocks-cms-stubs pubblica gli stub iniziali di proprietà del pacchetto.
• Questi tag non modificano da soli il comportamento a runtime e restano inerti finché vendor:publish non viene eseguito esplicitamente.

• L'obiettivo a lungo termine resta l'aggiornamento del pacchetto gestito da Composer seguito da passaggi di runtime controllati.
• I passaggi previsti dopo l'aggiornamento potranno in seguito includere migrazioni, sincronizzazione dei tipi di blocco, pulizia della cache o pubblicazione o sincronizzazione degli asset, ma solo quando quelle risorse di proprietà del pacchetto saranno reali e collegate intenzionalmente.
• L'artefatto di rilascio canonico è ora la root del pacchetto stessa, non la root del repository di manutenzione. Gli ZIP di aggiornamento sono validi quando la root dell'archivio, oppure una singola directory contenitore di primo livello, contiene il composer.json del pacchetto e la struttura src/, config/, resources/, database/, routes/ e public/ attesa da fklavyenet/webblocks-cms.
• La vecchia forma di archivio dell'updater gestita dalla root è intenzionalmente dismessa per gli aggiornamenti moderni nativi di pacchetto. Resta valida solo come artefatto ponte esplicito per installazioni precedenti al modello nativo di pacchetto come 1.31.53, il cui updater non è ancora in grado di validare ZIP con root di pacchetto.
• I metadati di rilascio con root di pacchetto devono richiedere un updater in grado di fare da ponte (minimum_client_version pari a 1.32.18 o successivo). Le installazioni più vecchie dovrebbero ricevere prima il ponte compatibile e usare poi l'artefatto moderno con root di pacchetto, dopo che il ponte ha installato la validazione e il codice di applicazione nativi di pacchetto.
• Durante l'attuale transizione, l'applicazione Laravel di root resta di proprietà dell'installazione e continua a eseguire modalità di manutenzione, migrazioni, seeder, comandi di sincronizzazione, pulizie della cache e persistenza della versione installata dalla root di installazione.
• Gli aggiornamenti in-app applicano ora l'artefatto di pacchetto validato in packages/webblocks-cms/ e, quando l'autoload di Composer mostra che il runtime consumatore attivo carica ancora WebBlocks\Cms\ da vendor/fklavyenet/webblocks-cms/..., anche nella corrispondente root di runtime sicura del pacchetto vendor. Non sovrascrivono lo shell di root di proprietà dell'installazione, le sovrascritture di configurazione di root, le migrazioni di root, project/, storage/, .env o public/site/.
• Gli archivi ponte gestiti dalla root non sono un allentamento della validazione moderna. Un archivio ponte deve mantenere la vecchia forma con artisan più composer.json di root unicamente per compatibilità con i client legacy e deve installare codice di aggiornamento in grado di imporre poi la forma rigorosa con root di pacchetto di fklavyenet/webblocks-cms.
• Il checkpoint di completamento dei confini v1.31.65 mantiene questo solo come nota di obiettivo. L'attuale comportamento di Composer nella root e il flusso di aggiornamento a runtime restano autorevoli finché non esisterà la prima vera porzione di runtime di proprietà del pacchetto.

Flusso di installazione di destinazione una volta pronta la separazione pacchetto-starter:

• composer require fklavyenet/webblocks-cms
• la root Laravel a livello di installazione resta responsabile di .env, del composer.json di root, di storage/, delle sovrascritture di configurazione di proprietà dell'installazione e di eventuali personalizzazioni specifiche dell'installazione in project/ ancora presenti durante la transizione
• il package discovery dovrebbe caricare WebBlocks\Cms\WebBlocksCmsServiceProvider
• la diagnostica del pacchetto, come webblocks:package-status, dovrebbe confermare la prontezza del pacchetto senza modificare lo stato

Flusso di aggiornamento di destinazione una volta che gli aggiornamenti del pacchetto gestiti da Composer diventeranno autorevoli:

• composer update fklavyenet/webblocks-cms
• eseguire le migrazioni
• svuotare le cache dove necessario
• pubblicare o sincronizzare gli asset del pacchetto solo quando lo richiedono asset reali del pacchetto
• eseguire la diagnostica del pacchetto, come webblocks:package-status
• sincronizzare lo stato della versione installata solo quando l'aggiornamento corrisponde a un reale confine di rilascio
• eseguire separatamente la riparazione esplicita del catalogo quando le righe del catalogo distribuito necessitano manutenzione

Regola di compatibilità attuale:

• oggi quelle note sui flussi di installazione e aggiornamento sono solo documentazione dello stato di destinazione
• l'attuale comportamento di Composer nella root, il comportamento dell'installer e il comportamento di System Update in-app restano autorevoli finché una successiva fase dedicata al flusso di aggiornamento non li cambierà intenzionalmente

• La direzione a lungo termine resta un progetto starter separato che dipenda da fklavyenet/webblocks-cms come pacchetto.
• L'attuale pacchetto interno al repository esiste per stabilire confini e responsabilità prima di tentare quella separazione.
• La separazione dello starter dovrebbe avvenire solo dopo la riprogettazione dei confini di root rimanenti: runtime di installazione/autenticazione/profilo, modello User di proprietà dell'app, autorità sulle migrazioni di root, autorità operativa di aggiornamento/installazione di root e il percorso attivo degli asset di runtime public/cms di root.

• Spostate un tipo di risorsa alla volta dal confine riservato alla proprietà attiva del pacchetto.
• Iniziate solo quando la regola esatta di caricamento a runtime, la gestione delle sovrascritture di installazione e il comportamento di pubblicazione/aggiornamento sono chiari per quel tipo di risorsa.
• Preferite piani di fase mirati, come viste del pacchetto, migrazioni del pacchetto o asset pubblici del pacchetto, invece di mescolare più tipi di risorse di runtime in un unico checkpoint.
• Tenete gli spostamenti di sorgente ad alto impatto sul runtime dietro audit dedicati delle dipendenze, invece di inserirli nel lavoro pilota sui confini delle risorse.

Spostate il comportamento di aggiornamento verso aggiornamenti del pacchetto CMS gestiti da Composer, più passaggi successivi controllati come migrazioni, pulizia della cache e pubblicazione o sincronizzazione degli asset quando serve. La riparazione del catalogo resta un flusso di manutenzione esplicito dell'operatore invece di un passaggio di aggiornamento predefinito.

L'attuale checkpoint di prontezza include ora:

• autoload Composer del pacchetto per WebBlocks\Cms\Database\Seeders\
• il collegamento di sviluppo mantenuto tramite repository di percorso nella root verso packages/webblocks-cms
• documentazione esplicita del fatto che l'attuale comportamento di System Update nella root resta autorevole finché una successiva fase dedicata al flusso di aggiornamento non lo cambierà intenzionalmente

Introducete la direzione del progetto starter separato, come fklavyenet/webblocks-cms-starter, in modo che le nuove installazioni partano da una root Laravel di proprietà dell'utente che dipende dal pacchetto CMS, invece di clonare il repository del core CMS nella root del progetto.

L'attuale checkpoint aggiunge soltanto il lavoro preparatorio sui confini per quella futura separazione:

• più seeder di proprietà del CMS vivono ora nel pacchetto invece che nel namespace dell'app di root
• più helper di supporto a runtime a basso rischio vivono ora in src/Support/ del pacchetto
• i wrapper di compatibilità in app/ di root non vengono più mantenuti per impostazione predefinita; i wrapper PHP omologhi del pacchetto sono stati rimossi, mentre i percorsi di compatibilità di Blade, seeder e asset di runtime di root restano dove ancora servono
• i metadati composer del pacchetto, la discovery del provider, il collegamento di sviluppo tramite repository di percorso e il flusso di destinazione documentato di composer require o composer update formano ora la linea di base di prontezza della fondazione starter

Le installazioni esistenti avranno bisogno di un percorso di migrazione conservativo:

• mantenere funzionanti le installazioni attuali finché la transizione al pacchetto è incompleta
• evitare grandi spostamenti in un solo passaggio che mescolino refactoring di runtime e modifiche di packaging
• preservare i file di root specifici dell'installazione come stato di progetto di proprietà dell'utente
• smettere di affidarsi alla sostituzione dei file del core CMS su tutta la root come meccanismo di aggiornamento
• introdurre indicazioni chiare per rimuovere i file obsoleti del core CMS gestiti dalla root una volta che esistono i loro sostituti di proprietà del pacchetto

La transizione dovrebbe privilegiare movimenti incrementali a basso rischio rispetto a una riscrittura unica.

Il consolidamento della transizione al pacchetto è completo per tutto il sorgente di proprietà del CMS spostabile in sicurezza in questo repository.

• L'autorità del pacchetto copre ora i domini di sorgente runtime di rotte, viste, modelli, seeder, partial condivisi, layout di amministrazione e supporto del CMS spostabili in sicurezza.
• Le classi App\... omologhe del pacchetto sono state rimosse dall'albero app del repository di manutenzione; i file Blade di root, i seeder di root e le copie di runtime in public/cms/... di root restano intenzionalmente al loro posto come wrapper o percorsi di compatibilità.
• Gli URL degli asset di runtime attivi usano ancora i percorsi di compatibilità public/cms/... di root anche dove esistono file sorgente omologhi di proprietà del pacchetto sotto packages/webblocks-cms/public/cms/....
• I confini finali rimanenti sono il runtime di installazione/autenticazione/profilo, il modello User di proprietà dell'app, l'autorità sulle migrazioni di root, l'autorità operativa di aggiornamento/installazione di root e il design della futura separazione starter.
• A causa di questi blocchi il pacchetto non è ancora pronto per la separazione starter, anche se il lavoro sicuro di consolidamento del sorgente di proprietà del CMS è completo.

Questa modifica del repository è solo il primo passo di transizione a basso rischio:

• aggiunge documentazione di architettura
• crea lo scheletro del pacchetto nel repository in packages/webblocks-cms/
• aggiunge un composer.json minimo per il pacchetto
• aggiunge un WebBlocks\Cms\WebBlocksCmsServiceProvider
• collega il progetto di root per richiedere il pacchetto localmente tramite percorso

Il provider definisce ora il contratto di bootstrap del pacchetto per le future risorse del pacchetto, ma quelle risorse non sono ancora autorevoli perché gli attuali file di runtime del CMS vivono ancora nell'applicazione di root.

Il pilota v1.31.62 rende più concreti quei confini di risorse del pacchetto aggiungendo file marcatori di confine riservati espliciti sotto routes/, resources/views/, database/migrations/, public/ e stubs/ del pacchetto. Queste directory esistono ora come destinazioni documentate di proprietà del pacchetto per le fasi successive, ma il loro contenuto resta un segnaposto non autorevole in questo checkpoint.

Il pilota v1.31.63 fa avanzare solo il confine del namespace delle viste del pacchetto aggiungendo una vera vista Blade diagnostica interna sotto resources/views/diagnostics/package-status.blade.php del pacchetto e una sonda di rendering opzionale in sola lettura webblocks:package-status --view-check. Questo dimostra il caricamento delle viste basato sul namespace del pacchetto con una vera vista di proprietà del pacchetto, lasciando autorevole la risoluzione delle viste di amministrazione e pubbliche di root.

Il pilota v1.31.64 fa avanzare solo il confine delle rotte del pacchetto aggiungendo un vero file di rotte diagnostiche del pacchetto sotto routes/diagnostics.php, mantenendo il caricamento delle rotte esplicitamente disattivato nel runtime normale. Questo dimostra i confini di proprietà dei file di rotta del pacchetto senza spostare alcuna rotta attiva di amministrazione o pubblica di root.

Il checkpoint v1.31.65 completa i restanti pilota di confine inerti mantenendo le migrazioni del pacchetto esplicitamente disattivate da guardia, confermando che la pubblicazione di asset pubblici e stub del pacchetto resta inerte finché non esistono file reali di proprietà del pacchetto, e documentando gli aggiornamenti del pacchetto gestiti da Composer come confine di destinazione senza modificare l'attuale flusso di aggiornamento di root.

La release v1.32.0 avvia quel movimento pianificato con le fasi 1-2 di migrazione del runtime protette da guardie:

• la porzione di runtime diagnostica del pacchetto è reale e di proprietà del pacchetto end to end, tramite un controller del pacchetto più la vista diagnostica già esistente del pacchetto, ma resta disattivata da guardia per impostazione predefinita
• una porzione mirata di runtime di amministrazione è ora di proprietà del pacchetto end to end tramite routes/admin.php, src/Http/Controllers/Admin/PackageAdminStatusController.php e resources/views/admin/runtime-status.blade.php del pacchetto, ma resta disattivata da guardia per impostazione predefinita su un percorso riservato
• una porzione mirata di runtime pubblico è ora di proprietà del pacchetto end to end tramite routes/public.php, src/Http/Controllers/Public/PackagePublicStatusController.php e resources/views/public/runtime-status.blade.php del pacchetto, ma resta disattivata da guardia per impostazione predefinita su un percorso riservato
• webblocks:package-status riporta ora la porzione di runtime diagnostica, la porzione admin del pacchetto, la porzione pubblica del pacchetto e le guardie di rotta esplicite, ancora in sola lettura
• le rotte e le viste di root restano autorevoli per il runtime CMS esistente al di fuori di questi percorsi riservati al pacchetto e protetti da guardie
• config/webblocks-cms.php del pacchetto possiede ora valori di configurazione di transizione espliciti: diagnostica, rotte pubbliche di stato, rotte admin di stato e caricamento delle migrazioni del pacchetto restano disattivati per impostazione predefinita, mentre il caricamento delle rotte admin del pacchetto è abilitato per dare autorità attiva alle rotte di amministrazione di proprietà del pacchetto

Le seguenti note storiche dei checkpoint descrivono come è stata introdotta l'autorità del pacchetto. Dove menzionano wrapper App\... di root, l'attuale ampia pulizia dell'app di root sostituisce quello stato: i wrapper PHP omologhi del pacchetto ora sono intenzionalmente assenti, salvo quanto elencato nello stato attuale di pulizia dell'app di root riportato sopra.

L'attuale checkpoint di autorità del runtime del passo 1 estende ulteriormente quel confine:

• le rotte di amministrazione attive del CMS si caricano ora da routes/admin.php del pacchetto, mentre routes/web.php di root è ridotto al caricamento di installazione, autenticazione, profilo e compatibilità
• le rotte pubbliche attive del CMS si caricano ora da routes/public.php del pacchetto, incluse home, home localizzata, ricerca, ricerca localizzata, ricerca JSON, visualizzazione pagina, visualizzazione pagina localizzata, invii dei contatti, sincronizzazione del consenso privacy e admin-api.*
• controller pubblici di proprietà del pacchetto sostengono ora quella porzione di ingresso pubblico sotto packages/webblocks-cms/src/Http/Controllers/Public/
• un ContactMessageRequest di proprietà del pacchetto e viste di ingresso pubblico di proprietà del pacchetto sostengono ora gli entrypoint delle rotte pubbliche spostate
• App\Http\Controllers\PageController, PublicSearchController, ContactMessageController, PublicPrivacyConsentController e App\Http\Requests\ContactMessageRequest di root sono stati poi rimossi in quanto wrapper omologhi ridondanti del pacchetto
• i modelli e le classi di supporto di root restano solo dove servono domini di proprietà dell'host o di esplicita transizione; Users, installazione/profilo/autenticazione, i percorsi di runtime degli asset pubblici/admin di root, le migrazioni e il comportamento di System Update restano confini, quindi il pacchetto non è ancora pronto a fungere da runtime starter pienamente indipendente senza un'estrazione più profonda

L'attuale checkpoint di rendering pubblico del passo 2 estende ulteriormente l'autorità del pacchetto dietro quelle rotte pubbliche già di proprietà del pacchetto:

• il file del pacchetto resources/views/layouts/public.blade.php possiede ora il guscio di layout pubblico attivo sotto il namespace webblocks-cms::
• i file del pacchetto resources/views/pages/show.blade.php, resources/views/search/show.blade.php, resources/views/search/partials/modal.blade.php e pages/partials/slot*.blade.php possiedono ora il guscio di pagina pubblico attivo, il guscio di ricerca pubblico, la finestra modale di ricerca pubblica e il livello di rendering delle voci di slot
• i file di root resources/views/layouts/public.blade.php, resources/views/pages/show.blade.php, resources/views/search/show.blade.php, resources/views/search/partials/modal.blade.php, resources/views/pages/partials/slot.blade.php e resources/views/pages/partials/block.blade.php restano ora solo come wrapper di compatibilità che puntano alle viste con namespace di proprietà del pacchetto
• il supporto al rendering pubblico di proprietà del pacchetto include ora PageRouteResolver, PublicPagePresenter, PublicSharedSlotResolver, SlotWrapperResolver, SiteAssetResolver, PublicSearchQuery, PublicOverlayRegistry, PublicBodyEndRegistry, TrustedHtmlOverlayExtractor, SiteResolver, ResolvedSite e VisitorEventLogger
• le classi di root App\Support\... per quegli aspetti del rendering pubblico sono state rimosse in seguito, una volta che gli interni del pacchetto e le rotte non le richiedevano più
• la directory del pacchetto resources/views/pages/partials/blocks/* possiede ora l'intero albero di partial del renderer pubblico dei blocchi incluso, come un unico lotto coerente del pacchetto
• i file di root resources/views/pages/partials/blocks/ restano ora come sottili wrapper di compatibilità che delegano alle viste webblocks-cms::pages.partials.blocks. corrispondenti
• Block::publicRenderView() risolve ora i tipi di blocco core inclusi dando priorità ai partial di blocco con namespace di proprietà del pacchetto, mentre i renderer di blocco di root specifici dell'installazione o personalizzati restano disponibili tramite il percorso di ripiego di root esistente quando non esiste un partial corrispondente nel pacchetto
• la base del modello pubblico vive ora sotto src/Models/ del pacchetto; i wrapper di root App\Models\... corrispondenti sono stati rimossi in seguito, dopo che i test del pacchetto e dei consumatori nuovi hanno dimostrato che non erano necessari
• Page, PageTranslation, PageSlot e Block vivono ora anch'essi sotto src/Models/ del pacchetto, senza wrapper di root corrispondenti
• User resta intenzionalmente di proprietà dell'applicazione e della root e non fa parte dell'obiettivo di migrazione dei modelli nel pacchetto
• la directory public/cms/ del pacchetto include ora i file CSS e JS di runtime pubblico attivi necessari al livello di layout pubblico e di rendering dei blocchi spostato nel pacchetto, e vendor:publish --tag=webblocks-cms-assets pubblica ora quegli asset reali del pacchetto nel percorso di compatibilità di root public/cms
• il runtime attivo continua a servire public/cms/... dall'installazione di root per compatibilità, mentre l'installazione e System Update aggiornano in quel percorso gli asset CMS di proprietà del pacchetto
• le migrazioni di root restano autorevoli per i checkout mantenuti da sorgente con il segnale esplicito di autoload Composer nella root, mentre i System Update nativi del pacchetto saltano le migrazioni dell'applicazione Laravel ospite ed eseguono solo le migrazioni di aggiornamento dedicate del pacchetto quando presenti
• System Update, il flusso di installazione, backup o ripristino e il più ampio runtime del livello di progetto restano invariati in questo lotto
• la validazione con consumatori o starter package non è ancora realistica dopo questo checkpoint, perché il runtime dipende ancora dalle migrazioni di root, dai percorsi degli asset di compatibilità di root, dai flussi di amministrazione e installazione/aggiornamento di proprietà della root e dal confine intenzionale del modello User di root di proprietà dell'applicazione

L'attuale checkpoint del runtime di amministrazione di Site e Locale sposta un'altra fetta coerente dell'amministrazione dietro l'albero di rotte di amministrazione di proprietà del pacchetto:

• i controller di proprietà del pacchetto gestiscono ora l'amministrazione di Site, la gestione di Site Domain, la gestione di Site Variable e l'amministrazione di Locale sotto packages/webblocks-cms/src/Http/Controllers/Admin/
• le Form Request di proprietà del pacchetto, i modelli SiteLocale e SiteVariable e i servizi di supporto direttamente collegati a Site o Locale vivono ora sotto src/ del pacchetto, senza wrapper di root App\... corrispondenti
• le directory del pacchetto resources/views/admin/sites/, resources/views/admin/sites/domains/, resources/views/admin/domains/ e resources/views/admin/locales/ possiedono ora gli alberi Blade attivi di amministrazione di Site, Domain e Locale attraverso il namespace webblocks-cms::
• i file Blade di root di Site, Domain e Locale restano ora come sottili wrapper di compatibilità che renderizzano le viste corrispondenti di proprietà del pacchetto
• questo lotto intenzionalmente non sposta migrazioni, flussi di installazione/aggiornamento, backup/ripristino, proprietà di autenticazione/profilo/User, proprietà della configurazione di root o l'autorità sugli asset public/cms

La configurazione predefinita di proprietà del pacchetto è ormai avviata per webblocks-updates, mentre il file di configurazione di root resta autorevole come override dell'installazione durante la transizione.

La configurazione predefinita di proprietà del pacchetto è ormai avviata anche per contact, mentre il file di configurazione di root resta autorevole come override dell'installazione durante la transizione.

La configurazione predefinita di proprietà del pacchetto è ormai avviata anche per demo_media, mentre il file di configurazione di root resta autorevole come override dell'installazione durante la transizione.

La configurazione predefinita di proprietà del pacchetto è ormai avviata anche per cms, mentre il file di configurazione di root resta autorevole come override dell'installazione durante la transizione.

Il bootstrap della console di proprietà del pacchetto è ora dimostrato anche dal comando diagnostico di sola lettura webblocks:package-status.

Il namespace delle viste del pacchetto webblocks-cms è ora registrato in sicurezza anche come pilota del confine di pacchetto, e v1.31.63 dimostra quel namespace con una vista diagnostica reale di proprietà del pacchetto. La risoluzione attiva delle viste di root resta autorevole perché nessuna vista di amministrazione o pubblica attiva del runtime CMS è stata spostata nel pacchetto.

Il confine delle rotte del pacchetto è ora dimostrato anche con un file di rotte diagnostiche reale di proprietà del pacchetto, ma la risoluzione attiva delle rotte di amministrazione e pubbliche di root resta autorevole, perché le rotte diagnostiche del pacchetto restano disabilitate dai guard nel runtime normale e nessun file di rotte di root attivo è stato spostato nel pacchetto.

I confini di migrazione, asset pubblici e stub del pacchetto sono ora anche esplicitamente completati come piloti riservati e inerti, e il confine del flusso di aggiornamento gestito da Composer è documentato solo come direzione di destinazione. Nessuna migrazione di root attiva, nessun asset pubblico di root, nessun comportamento degli stub di root e nessun comportamento del flusso di aggiornamento di root è ancora passato sotto l'autorità del pacchetto.

Il primo spostamento di sorgente PHP di proprietà del pacchetto è ora completo per SearchTextNormalizer, spostato da app/Support/Search/ a src/Support/Search/ del pacchetto mantenendo il comportamento invariato.

Il confine del supporto Search resta intenzionalmente stretto in questa fase: SearchTextNormalizer e il piccolo value object di risultato PublicSearchRebuildResult sono ora di proprietà del pacchetto, mentre l'indicizzazione della ricerca e l'orchestrazione delle query restano di proprietà della root finché le loro dipendenze da database e runtime non saranno migrate deliberatamente.

È ora documentato anche il primo audit di Support non legato a Search: MediaKindResolver, DatabaseExecutionStrategyResolver, SiteHandle e SiteDomainNormalizer sono stati esaminati e nessuna classe aggiuntiva è stata spostata, perché ciascuna attraversa ancora almeno un confine di rischio attuale di questa fase iniziale.

Il primo spostamento di sorgente del supporto Contact è ora completo anche per ContactMessageNotificationResult, spostato da app/Support/Contact/ a src/Support/Contact/ del pacchetto mantenendo il comportamento invariato, mentre il servizio di notifica e il flusso di runtime dei contatti restano di proprietà della root.

Il primo spostamento di sorgente del supporto BlockTypes è ora completo anche per BlockTypeContract, spostato da app/Support/BlockTypes/ a src/Support/BlockTypes/ del pacchetto mantenendo il comportamento invariato, mentre il registro, il percorso della finestra modale dei contratti nell'amministrazione e il comando di audit restano di proprietà della root.

Anche LayoutMarkup è stato esaminato come possibile spostamento circoscritto di un helper di Pages e resta per ora di proprietà della root, perché i suoi riferimenti attuali attraversano ancora la validazione delle richieste di page layout, il rendering dei form di amministrazione e il comportamento pubblico dei wrapper di slot.

Il primo spostamento di sorgente del supporto Formatting è ora completo anche per InlineRichTextRenderer, spostato da app/Support/Formatting/ a src/Support/Formatting/ del pacchetto mantenendo il comportamento invariato, mentre SafeRichTextRenderer e il suo contratto di sanitizzazione restano di proprietà della root.

Il successivo checkpoint di supporto al runtime a basso rischio è ora completo anche per quattro helper circoscritti che restano vicini allo stato delle query di amministrazione e alla paginazione:

• AdminPagination vive ora in src/Support/Admin/ del pacchetto
• BlockTypeIndexState vive ora in src/Support/BlockTypes/ del pacchetto
• MediaIndexState vive ora in src/Support/Media/ del pacchetto
• PageIndexState vive ora in src/Support/Pages/ del pacchetto
• i wrapper di root App\Support\... per questi helper sono stati rimossi in seguito; gli import del pacchetto sono autorevoli

Il primo spostamento del confine dei seeder di proprietà del pacchetto è ora completo anche per i cataloghi a basso rischio:

• ora di proprietà del pacchetto: IconCatalogSeeder, PageTypeSeeder, LayoutTypeSeeder, SlotTypeSeeder
• ora di proprietà del pacchetto anche: CoreCatalogSeeder, come spostamento del confine dell'aggregatore di cataloghi
• le classi di root Database\Seeders\... restano come wrapper di compatibilità
• CoreCatalogSeeder mantiene comunque stabili gli entrypoint di root delegando tramite il wrapper di root, continuando a chiamare PageLayoutSeeder e BlockTypeSeeder di proprietà della root
• PageLayoutSeeder, BlockTypeSeeder e il seeding attivo di System Update restano di proprietà della root fino a una fase dedicata successiva

Il successivo lotto isolato di runtime di proprietà del pacchetto è ora completo anche per la gestione del catalogo delle icone:

• ora di proprietà del pacchetto: SyncWebBlocksUiIconsCommand, IconCatalogController, IconCatalogItemUpdateRequest, IconCatalog e WebBlocksIconManifestSyncer
• le classi di root App\Http\Controllers\Admin\IconCatalogController, App\Http\Requests\Admin\IconCatalogItemUpdateRequest, App\Support\Icons\... e App\Console\Commands\SyncWebBlocksUiIconsCommand sono state rimosse in seguito come wrapper ridondanti delle controparti del pacchetto
• le rotte attive di amministrazione del catalogo delle icone puntano ora direttamente al controller del pacchetto, e icons:sync-webblocks-ui è ora registrato dal service provider del pacchetto con la classe di comando del pacchetto
• le definizioni attive delle rotte di amministrazione del catalogo delle icone vivono ora in routes/admin.php del pacchetto invece che in routes/web.php di root
• i wrapper PHP di root del catalogo delle icone non sono più disponibili; l'autorità attiva su rotte e console risiede nel pacchetto
• ora di proprietà del pacchetto anche: le viste Blade attive di indice e di finestra modale di modifica del catalogo delle icone nell'amministrazione, sotto packages/webblocks-cms/resources/views/admin/system/icons/
• i file Blade di root del catalogo delle icone restano come wrapper di compatibilità che includono le viste con namespace del pacchetto, ma il controller del pacchetto renderizza direttamente webblocks-cms::admin.system.icons.index
• questo lotto resta unicamente nell'ambito dell'amministrazione e della sincronizzazione del catalogo delle icone e intenzionalmente non sposta la proprietà del runtime più ampio di Pages, Blocks, indicizzazione Search, Sites, Updates, Install, Backup o Restore, Export o Import, né del rendering pubblico
• webblocks:package-status segnala ora i file di runtime delle icone di proprietà del pacchetto e l'assenza dei corrispondenti wrapper PHP di root, come parte della diagnostica di transizione di sola lettura

Il successivo lotto più ampio di estrazione del runtime di amministrazione è ora completo anche per le principali superfici di gestione editoriale e dei cataloghi:

• routes/admin.php del pacchetto è ora autorevole non solo per la gestione del catalogo delle icone, ma anche per gli handler attivi delle rotte di amministrazione di Pages, Blocks, Media, Shared Slots, Navigation, Block Types e Page Layouts
• ora di proprietà del pacchetto: i controller di amministrazione autorevoli per quelle fette, sotto packages/webblocks-cms/src/Http/Controllers/Admin/
• ora di proprietà del pacchetto: le form request di amministrazione autorevoli per quelle fette, sotto packages/webblocks-cms/src/Http/Requests/Admin/
• ora di proprietà del pacchetto: i servizi di supporto per blocchi, media, navigazione, pagine, page layout e shared slot, sotto packages/webblocks-cms/src/Support/
• ora di proprietà del pacchetto: gli alberi Blade di amministrazione attivi sotto packages/webblocks-cms/resources/views/admin/blocks/, admin/media/, admin/navigation/, admin/block-types/, admin/pages/, admin/shared-slots/, admin/page-layouts/ e admin/page-layout-slots/
• i wrapper PHP di root App\Http\Controllers\Admin\..., App\Http\Requests\Admin\... e App\Support\... per quelle fette spostate sono stati rimossi in seguito come wrapper ridondanti delle controparti del pacchetto
• i file di root resources/views/admin/... per quegli alberi spostati restano ora come wrapper di compatibilità che includono le viste webblocks-cms::admin.* corrispondenti
• un'eccezione resta intenzionalmente concreta nella root: resources/views/admin/blocks/types/partials/rich-text-editor.blade.php conserva ancora il markup reale, perché la copertura di compatibilità legge quel file di root direttamente invece di risolverlo solo tramite il namespace del pacchetto
• questo lotto intenzionalmente non sposta Users, backup, aggiornamenti, impostazioni di sistema, flusso di installazione, migrazioni, percorsi degli asset di runtime di root o il modello User di proprietà dell'applicazione
• webblocks:package-status, insieme a una copertura di bootstrap mirata, segnala ora i più ampi file di runtime di amministrazione di proprietà del pacchetto e l'assenza dei corrispondenti wrapper PHP di root

Il lotto mirato del runtime operativo di amministrazione è ora anch'esso di proprietà del pacchetto:

• i controller di proprietà del pacchetto gestiscono ora l'interfaccia Dashboard, quella di revisione dei Contact Messages in amministrazione, quella dei Visitor Reports e quella di stato o ricostruzione di System Search, sotto packages/webblocks-cms/src/Http/Controllers/Admin/
• le classi di supporto di proprietà del pacchetto includono ora il servizio di query per i report dei visitatori e l'helper leggero per lo stato dello schema della ricerca pubblica; l'architettura completa di indicizzazione della ricerca e il comportamento del comando search:rebuild restano invariati dietro i punti di ingresso di compatibilità nella radice
• nel pacchetto, resources/views/admin/dashboard.blade.php, admin/contact-messages/*, admin/reports/visitors/index.blade.php e admin/system/search.blade.php sono ora i proprietari delle superfici Blade operative attive dell'amministrazione tramite lo spazio dei nomi webblocks-cms::
• i file di controller, supporto e Blade nella radice per quelle superfici operative restano wrapper di compatibilità leggeri
• questo lotto non sposta intenzionalmente System Update, System Backup, il backup/ripristino, l'esportazione/importazione dei siti, la promozione dei siti, l'installer, la proprietà di auth/profilo/User, le migrazioni né la proprietà della configurazione nella radice, e nemmeno l'autorità sugli asset di public/cms nella radice

Il follow-up sicuro rimanente sulle rotte operative attive è ora anch'esso completo:

• i controller di proprietà del pacchetto gestiscono ora anche Slot Types e System Settings sotto packages/webblocks-cms/src/Http/Controllers/Admin/
• le Form Request di proprietà del pacchetto includono ora anche SystemSettingsRequest sotto packages/webblocks-cms/src/Http/Requests/Admin/
• nel pacchetto, resources/views/admin/slot-types/index.blade.php e resources/views/admin/system/settings.blade.php sono ora i proprietari delle superfici Blade attive tramite lo spazio dei nomi webblocks-cms::
• nella radice, App\Http\Controllers\Admin\SlotTypeController, App\Http\Controllers\Admin\SystemSettingsController, App\Http\Requests\Admin\SystemSettingsRequest e i file Blade corrispondenti nella radice restano wrapper di compatibilità
• questo follow-up continua intenzionalmente a non spostare l'implementazione di System Update, il backup o il ripristino, l'installer, la proprietà di auth/profilo/User, le migrazioni né la proprietà della configurazione nella radice, e nemmeno l'autorità sugli asset a runtime di public/cms nella radice

Lo stato dello shell di amministrazione e del confine degli asset è il seguente:

• le viste di amministrazione di proprietà del pacchetto estendono webblocks-cms::layouts.admin, e il wrapper di compatibilità nella radice resources/views/layouts/admin.blade.php è stato rimosso, così gli errori di spazio dei nomi nei consumatori del pacchetto falliscono localmente
• nel pacchetto, public/cms/ contiene anche i file sorgente CSS e JS di amministrazione corrispondenti al set di asset di amministrazione attivo nella radice, mentre i percorsi public/cms/... nella radice restano il livello di compatibilità a runtime
• le migrazioni, l'updater, il backup/ripristino, l'esportazione/importazione, la promozione, auth/User, l'installer, la configurazione nella radice e l'autorità sugli asset a runtime restano fuori dal confine immediato dello shell di amministrazione del pacchetto

I lotti selezionati di partial e componenti condivisi dell'amministrazione sono ora di proprietà del pacchetto:

• ora di proprietà del pacchetto: webblocks-cms::admin.partials.page-header, flash, listing-filters, page-actions, pagination e audit-actor
• ora di proprietà del pacchetto: webblocks-cms::components.admin.form-actions, utilizzato dalle viste del pacchetto tramite <x-webblocks-cms::admin.form-actions>
• ora di proprietà del pacchetto: webblocks-cms::layouts.admin, utilizzato dalle viste di amministrazione di proprietà del pacchetto tramite @extends('webblocks-cms::layouts.admin', ...)
• nella radice, resources/views/admin/partials/{page-header,flash,listing-filters,page-actions,pagination,audit-actor}.blade.php restano wrapper di compatibilità
• nella radice, resources/views/layouts/admin.blade.php non esiste più; le viste di amministrazione dei plugin e del pacchetto non devono usare il percorso storico layouts.admin
• nella radice, resources/views/components/admin/form-actions.blade.php resta il wrapper di compatibilità per l'uso esistente di <x-admin.form-actions>
• le viste di amministrazione di proprietà del pacchetto preferiscono ora lo spazio dei nomi del pacchetto per il layout di amministrazione e per quei partial e componenti condivisi selezionati
• webblocks:package-status riporta ora il confine selezionato di partial e componenti condivisi dell'amministrazione, oltre all'inventario delle viste di amministrazione a runtime, che ora include il layout di amministrazione di proprietà del pacchetto e il relativo wrapper nella radice
• gli URL degli asset di amministrazione nella radice e l'autorità a runtime su public/cms, gli asset di brand, i confini auth/profilo/installazione/app/guest, le migrazioni, l'updater, il backup/ripristino e il lavoro su rilascio e versione restano invariati

La revisione dei confini del pacchetto della v1.32.15 aggiunge un audit statico, come gate di rilascio, per i riferimenti di amministrazione a runtime di proprietà del pacchetto:

• l'audit analizza packages/webblocks-cms/src/*/.php, packages/webblocks-cms/resources/views/*/.blade.php e packages/webblocks-cms/routes/*/.php
• fallisce in presenza di riferimenti di amministrazione presenti solo nella radice come view('admin.'), View::make('admin.'), response()->view('admin.'), @include('admin.'), @includeIf('admin.'), @extends('layouts.admin'), <x-admin., <x-auth-password-field, component('admin.') e i riferimenti diretti admin.blocks.types. di amministrazione dei blocchi nella radice
• le uniche eccezioni ammesse sono voci esatte di file e pattern nella allowlist, in cui il runtime del pacchetto controlla prima il nome webblocks-cms::... e usa il nome nella radice solo come fallback di compatibilità esplicito per le sovrascritture esistenti specifiche dell'installazione

Il checkpoint iniziale a basso rischio sul codice sorgente di helper e value object è ora considerato riuscito e completo per questa fase. Anche l'ambiente di sviluppo locale si è aggiornato correttamente dopo v1.31.60, a conferma che l'attuale cablaggio del pacchetto funziona nell'ambiente di sviluppo mantenuto.

Ulteriori spostamenti opportunistici di codice PHP a basso rischio sono ora sospesi. I futuri spostamenti di codice con forte impatto a runtime richiedono un piano di fase dedicato e un audit delle dipendenze, invece di altre piccole migrazioni opportunistiche.

Non sposta ancora il codice runtime esistente del CMS, non modifica il comportamento di System Update, non crea un progetto starter e non cambia gli attuali confini di proprietà a runtime.

Il passo 1 ha spostato nel pacchetto l'autorità sulle rotte attive del CMS, sia per l'amministrazione sia per il runtime pubblico, e ha spostato anche la porzione di ingresso delle rotte pubbliche per le richieste di pagina, ricerca, messaggio di contatto e consenso alla privacy. Il prossimo lotto dovrebbe ridurre la maggiore area di doppia proprietà rimasta dietro quell'autorità sulle rotte del pacchetto, invece di avviare un altro pilota ristretto.

Modelli che bloccano ancora un runtime indipendente del pacchetto:

• restano temporaneamente di proprietà della radice con una dipendenza dal pacchetto documentata: modelli di contenuto di amministrazione come BlockType, Media, SharedSlot, PageAsset, PageLayout, PageRevision, NavigationItem, SiteExport e SiteImport
• di proprietà del pacchetto con wrapper di compatibilità nella radice: Locale, Site, SiteDomain, SiteLocale, SiteVariable, Page, PageTranslation, PageSlot, Block, ContactMessage, PublicSearchIndex, VisitorEvent e SystemSetting
• probabilmente pronti per il pacchetto a breve, come follow-up ristretto di una porzione già di proprietà del pacchetto: IconCatalogItem
• deve restare di proprietà dell'applicazione: User

Confini delle viste che bloccano ancora un runtime indipendente del pacchetto:

• il layout pubblico del pacchetto, lo shell di pagina, lo shell di ricerca, il modale di ricerca, le viste di ingresso degli slot e l'albero distribuito dei partial di rendering pubblico dei blocchi sono ora autoritativi tramite lo spazio dei nomi webblocks-cms::
• nella radice, resources/views/pages/partials/blocks/* resta intenzionalmente presente come livello di wrapper di compatibilità, così che i renderer di blocchi specifici dell'installazione nella radice e i riferimenti diretti alle viste nella radice continuino a funzionare durante la transizione
• il rendering di amministrazione del pacchetto è ora autoritativo per admin/pages/, admin/blocks/, admin/shared-slots/, admin/media/, admin/navigation/, admin/block-types/, admin/page-layouts/, admin/page-layout-slots/, admin/sites/, admin/domains/ e admin/locales/* tramite lo spazio dei nomi webblocks-cms::, mentre i file Blade corrispondenti nella radice restano wrapper di compatibilità
• il rendering di amministrazione nella radice resta autoritativo per le schermate non ancora spostate, in particolare i wrapper di installazione/auth/profilo e i casi limite dell'utente di proprietà dell'applicazione, mentre il rendering del pacchetto è autoritativo per le schermate attive di trasferimento e promozione dei siti tramite webblocks-cms::

Confini di supporto e di servizi che bloccano ancora un runtime indipendente del pacchetto:

• ora di proprietà del pacchetto per la porzione di rendering pubblico: risoluzione delle rotte, presentazione delle pagine, presentazione degli Shared Slot, risoluzione dei wrapper di slot, estrazione degli overlay HTML attendibili, registri degli overlay pubblici o di fine body, orchestrazione delle query di ricerca pubblica, risoluzione del sito pubblico, risoluzione degli asset del sito e registrazione degli eventi dei visitatori
• spostare solo dopo lo spostamento dei modelli: i restanti livelli Pages o PublicRendering, Blocks, indicizzazione di Search, Navigation, SharedSlots o Revisions che poggiano ancora direttamente su modelli nella radice o su flussi di amministrazione più ampi
• mantenere per ora di proprietà della radice: Media, i flussi di portabilità di Sites, la sanitizzazione di Formatting e gli helper di Admin o Audit
• deve restare di proprietà della radice dell'installazione: Install, System o Updates, il backup o ripristino e gli writer della versione installata e dell'ambiente

Blocchi su request, comandi, asset, migrazioni e flusso di aggiornamento:

• molte Form Request di amministrazione potranno essere spostate in seguito con wrapper nella radice, una volta spostati i lotti corrispondenti di pagina, blocco, Shared Slot, media, sito e navigazione
• molte Form Request editoriali dell'amministrazione sono già state spostate con wrapper nella radice, ma le request di sistema, portabilità dei siti, aggiornamento, backup, installazione e le altre orientate alle operazioni restano di proprietà della radice
• i comandi di aggiornamento, backup, importazione, esportazione, promozione e installazione usati dal pacchetto devono restare esplicitamente delimitati, perché dipendono ancora dall'ambiente, dal filesystem, dagli archivi, da Composer, dalle migrazioni e dallo stato dell'installazione
• nella radice, public/cms/* continua a contenere gli asset che costituiscono i percorsi runtime autoritativi attivi, anche se public/cms/ ora include anche il CSS e il JS del layout pubblico spostati e può pubblicarli tramite webblocks-cms-assets
• le migrazioni nella radice restano autoritative per i checkout mantenuti da sorgente, con l'autorità di autoload di Composer nella radice del repository di manutenzione; i nuovi consumatori nativi del pacchetto installati con webblocks:install non devono eseguire le migrazioni dell'applicazione Laravel host durante System Update
• WebBlocks UI Manager non viene più distribuito all'interno del runtime del pacchetto CMS. Il suo codice sorgente si trova in plugins/webblocks-ui-manager per le build di manutenzione, e gli operatori lo installano manualmente come ZIP di plugin quando servono i flussi di rilascio o CDN di WebBlocks UI.
• la preparazione dei pacchetti di plugin della Fase 5 mantiene classi, viste, rotte, comandi, configurazione, spazi dei nomi delle impostazioni e prefissi di database di proprietà del plugin attribuibili agli handle dei plugin; i plugin disattivati o incompatibili restano inerti e non diventano responsabilità del core del CMS
• nei consumatori del pacchetto, System Updates esegue solo le migrazioni di aggiornamento dedicate di proprietà del pacchetto da vendor/fklavyenet/webblocks-cms/database/migrations/updates quando presenti; in caso contrario salta l'esecuzione delle migrazioni senza contrassegnare come eseguite migrazioni arbitrarie dell'host
• System Update resta una fase separata perché i suoi blocchi sono la mutazione dell'ambiente, le scritture su filesystem, l'esecuzione di Composer, i backup, le migrazioni, la persistenza della versione installata e lo stato operativo nella radice, non la proprietà di rotte o controller

• Consolidamento sicuro del codice di proprietà del CMS: completato
• Pulizia restante dell'inversione degli helper spostati: completata (WebBlocks\Cms\Support\Blocks\BlockTranslationWriter e CoreBlockTypeCatalogSyncer ora possiedono l'implementazione; le classi App\Support\Blocks\... nella radice restano solo wrapper di compatibilità)
• Consolidamento degli URL degli asset attivi a runtime: intenzionalmente incompleto; public/cms/... nella radice resta il percorso di compatibilità a runtime
• Prontezza per la separazione dello starter: non pronta
• Confini finali rimanenti: il runtime di installazione/auth/profilo, il modello User di proprietà dell'applicazione, l'autorità sulle migrazioni nella radice, l'autorità di aggiornamento e installazione nella radice e il futuro design della separazione dello starter

Lotto consigliato: eseguire una pulizia mirata della compatibilità di modelli e supporto per le porzioni di runtime già di proprietà del pacchetto, oppure avviare la prossima revisione della strategia di asset e brand dell'amministrazione ora che il layout di amministrazione e i file sorgente CSS o JS di amministrazione sono di proprietà del pacchetto. Mantenete attiva l'autorità sugli asset di amministrazione di public/cms nella radice finché la strategia degli asset di amministrazione non sarà esplicita.

Ambito completato in questo checkpoint:

• shell pubblico e viste di pagina: layouts.public, pages.show, search.show e search/partials/modal
• i partial di rendering delle voci di slot di pagina in resources/views/pages/partials/slot*.blade.php
• i partial distribuiti di rendering pubblico dei blocchi in resources/views/pages/partials/blocks/*
• il livello di supporto al rendering pubblico per la risoluzione delle rotte, la presentazione delle pagine pubbliche, la presentazione degli Shared Slot, la risoluzione dei wrapper di slot, l'estrazione degli overlay HTML attendibili, i registri degli overlay, l'orchestrazione delle query di ricerca, la risoluzione del sito, la risoluzione degli asset del sito e la registrazione degli eventi dei visitatori
• i wrapper di compatibilità nella radice dove i riferimenti a rotte, controller, request o viste necessitano ancora di punti di ingresso retrocompatibili nella radice

Ambito rinviato intenzionalmente da questo lotto:

• l'estrazione dei modelli Eloquent di proprietà del pacchetto per Locale, Site, SiteDomain, Page, PageTranslation, PageSlot, Block, ContactMessage, PublicSearchIndex, VisitorEvent e SystemSetting
• gli URL autoritativi degli asset del pacchetto a runtime e il relativo flusso di pubblicazione
• la riprogettazione dell'autorità sulle migrazioni nella radice
• l'estrazione di System Update e del flusso di installazione e aggiornamento

Perché questo lotto è il prossimo:

• l'autorità del pacchetto su rotte, controller, request, supporto e viste di amministrazione esiste già nelle principali porzioni del runtime di amministrazione
• i partial e i componenti condivisi di amministrazione selezionati e i loro casi limite ristretti sono ora stati spostati, lasciando i confini più ampi di shell e asset
• il layout di amministrazione di proprietà del pacchetto e i file sorgente CSS o JS di amministrazione di proprietà del pacchetto dipendono ancora dal caricamento attivo di asset e brand a runtime dalla radice, quindi il passo successivo dovrebbe essere una strategia deliberata di asset e brand per l'amministrazione, invece di un altro spostamento di shell
• il prossimo lavoro di estrazione ad alto valore consiste nel ridurre le restanti ipotesi di compatibilità di modelli e supporto oppure nel progettare la strategia di asset e brand dell'amministrazione, senza entrare in migrazioni, updater, backup/ripristino, esportazione/importazione, promozione, auth/User, installer, configurazione nella radice o autorità sugli asset

• batch di portabilità dei siti: Export o Import insieme a Promotion dovrebbero attendere finché i loro confini di archiviazione, backup e trasferimento non saranno esplicitamente verificati
• migrazioni, asset di runtime attivi, installer, backup/ripristino, autenticazione/User e System Update devono restare fasi dedicate e separate

Batch di riserva: una pulizia mirata della compatibilità residua di modelli e supporto per le porzioni di runtime già di proprietà del pacchetto.

Questa è l'opzione di riserva solo se i partial condivisi rivelano un accoppiamento inatteso con autenticazione, updater, backup o installazione, tale da rendere un pattern di wrapper sottile nella root troppo rumoroso per un piccolo batch di implementazione.