Coesistenza

Questo documento descrive come WebBlocks CMS debba coesistere con un altro prodotto host Laravel nella stessa applicazione. Registra soltanto la direzione architetturale; di per sé non implementa modifiche a rotte, configurazione, migrazioni, modelli, controller, installer, registrazione, inviti o autenticazione.

WebBlocks CMS può funzionare come CMS autonomo: in questo caso il CMS possiede l'esperienza di amministrazione principale, il rendering del sito pubblico e le operazioni sui contenuti dell'applicazione.

WebBlocks CMS può anche essere installato accanto a un altro prodotto host Laravel. In quel modello il prodotto host mantiene le proprie responsabilità di prodotto, mentre il CMS fornisce un comportamento opzionale di gestione del sito web e dei contenuti.

Nelle installazioni in coesistenza il CMS è un livello opzionale di sito web e contenuti. Non deve appropriarsi delle decisioni di dominio del prodotto host, della sua autorizzazione né delle sue rotte di amministrazione.

Il CMS deve restare package-first ed evitare collisioni con le rotte dell'applicazione host, le chiavi di configurazione, i namespace delle viste, la proprietà delle tabelle e altri confini a livello di applicazione.

L'installazione del pacchetto deve essere riprendibile su host condivisi. Prima di eseguire nuove migrazioni del CMS, webblocks:install rileva uno stato parziale delle tabelle del CMS e segnala le tabelle esistenti, il conteggio delle righe, le righe di migrazione corrispondenti e i conflitti noti di chiavi esterne. Le tabelle parziali vuote del CMS possono essere rinominate solo tramite il flag esplicito dell'installer --repair-partial. Le tabelle non vuote richiedono una revisione manuale e non devono essere eliminate, rinominate o trattate automaticamente come di proprietà del CMS.

Il prefisso di amministrazione del CMS deve essere configurabile.

Per le installazioni in coesistenza, il prefisso di amministrazione del CMS consigliato è /webadmin. L'applicazione host può essere proprietaria di /admin e il CMS non deve presumere che /admin sia sempre disponibile o di proprietà del CMS. Il segmento di percorso /cms è riservato agli asset statici del CMS, come /cms/css, /cms/js e /cms/brand.

Le installazioni autonome usano ora /webadmin come prefisso canonico di amministrazione del CMS. Documentazione, progettazione e lavoro di implementazione futuro devono mantenere chiaramente separati il comportamento attuale e la direzione a più lungo termine del prefisso configurabile.

I prefissi di amministrazione del CMS non devono mai riutilizzare il segmento di una directory fisica di asset pubblici. Nella versione v1.32.56 il prefisso canonico di amministrazione è passato a /webadmin perché try_files di Nginx può risolvere /cms/ come la directory fisica public/cms/ prima che Laravel veda la rotta. /cms deve restare riservato agli asset: non aggiungete alias o redirect di amministrazione sotto /cms di proprietà del CMS e non ripristinate rotte /admin di proprietà del CMS.

La soluzione finale evita del tutto la collisione tra rotta e filesystem invece di affidarsi a un passaggio di consegne tramite public/cms/index.php o a un ponte di front controller. public/cms/index.php deve restare assente sia dagli asset pubblici di root sia dagli asset pubblici del pacchetto.

Le pagine pubbliche usano il path della traduzione di pagina come URL canonico e possono includere percorsi con barre, come /docs/internal-content-api. I catchall delle pagine pubbliche devono continuare a lasciare /webadmin, /webadmin/api, /cms, /search, /search.json, /contact-messages, /install e le rotte di autenticazione dell'host ai rispettivi file di rotte. /p/... è solo compatibilità legacy e non deve essere generato come nuovo URL canonico.

Le rotte di amministrazione del CMS nel browser usano /webadmin, mentre /webadmin/api è riservato alle API JSON protette da token. Gli URL delle risorse devono essere prevedibili:

• collezione: /webadmin/{resource}
• creazione: /webadmin/{resource}/create
• modifica: /webadmin/{resource}/{id}/edit
• azione su un elemento: /webadmin/{resource}/{id}/{action}
• azione sulla collezione: /webadmin/{resource}/{action}

L'anteprima di pagina è un'azione su un elemento: GET /webadmin/pages/{page}/preview. Non aggiungete rotte di anteprima delle pagine del CMS sotto /admin, /cms, /webadmin/api, /webadmin/pages/preview/{page} o /webadmin/preview/pages/{page}.

Le anteprime di amministrazione autenticate devono mantenere separato il routing pubblico. Possono renderizzare contenuti di proprietà della pagina in bozza o in revisione per gli utenti CMS autorizzati, ma la rotta pubblica della pagina deve continuare a esporre solo pagine pubblicate e contenuti pubblici pubblicati.

All'interno di un host Laravel condiviso, login e registrazione sono responsabilità dell'applicazione host. La tabella condivisa users è il livello di identità e login.

Il CMS non deve richiedere un'identità utente duplicata nelle applicazioni co-installate. Quando le rotte di autenticazione del CMS fornite dal pacchetto sono attive, i redirect per ospiti dell'amministrazione CMS e le schermate di autenticazione del CMS devono usare la rotta /webadmin/login di proprietà del CMS, con nome di rotta webblocks.auth.login, invece del nome di rotta globale login, perché il prodotto host può essere proprietario di login per percorsi come /quiztem/login. Gli host che sostituiscono intenzionalmente l'autenticazione del CMS possono comunque mantenere il proprio flusso di login, ma le viste e i middleware CMS del pacchetto devono restare su nomi di rotta di proprietà del pacchetto.

L'autenticazione dimostra soltanto che un utente ha effettuato l'accesso. Non concede l'accesso al CMS.

L'autorizzazione del CMS deve essere decisa dal sistema di appartenenze e ruoli del CMS. Lo stato di super admin del CMS non rende l'utente amministratore del prodotto host, e lo stato di amministratore del prodotto host non rende l'utente super admin del CMS.

La tabella users è il livello di identità in un host Laravel condiviso. L'accesso al CMS è rappresentato da record di appartenenza o di ruolo di proprietà del CMS, non creando un secondo utente per la stessa persona.

I progetti di installer, registrazione e invito del CMS non devono creare righe users duplicate per lo stesso indirizzo email.

I flussi di installer, invito e registrazione che concedono l'accesso al CMS devono seguire questa sequenza:

1. Cercare un utente host esistente con lo stesso indirizzo email.
2. Riutilizzare quell'utente quando esiste.
3. Creare un nuovo utente solo quando non esiste alcun utente host corrispondente.
4. Aggiungere il record di appartenenza o di ruolo del CMS dopo aver risolto il record di identità.

Lo stato di super admin è un'assegnazione di appartenenza o di ruolo del CMS, non un tipo speciale di record users.

Il routing comune in coesistenza va progettato attorno a una proprietà chiara:

• /login -> identità e login dell'host
• /admin -> amministrazione del prodotto host, quando il prodotto host ne possiede una
• /webadmin -> amministrazione di WebBlocks CMS, consigliata per le installazioni in coesistenza
• /webadmin/login -> login del CMS di proprietà del pacchetto, quando le rotte di autenticazione CMS del pacchetto sono attive
• /webadmin/forgot-password e /webadmin/reset-password/{token} -> schermate di reimpostazione password del CMS di proprietà del pacchetto, quando le rotte di autenticazione CMS del pacchetto sono attive
• /cms/... -> asset statici di WebBlocks CMS
• rotte del sito pubblico -> rendering pubblico del CMS, quando il CMS possiede il contenuto pubblico della richiesta

Le installazioni autonome del CMS usano /webadmin per le rotte di amministrazione di proprietà del CMS, mentre le impostazioni di prefisso configurabile restano una direzione futura.

Le viste di autenticazione del CMS di proprietà del pacchetto devono usare rotte di autenticazione con prefisso CMS per le schermate di proprietà del CMS: webblocks.auth.login, webblocks.auth.logout e i nomi esistenti webblocks.auth.password.*. Se il set di rotte di autenticazione del pacchetto non prevede la registrazione al CMS, il login del CMS deve omettere il link Register invece di puntare a una rotta /register di root di proprietà dell'host.

L'implementazione attuale usa /webadmin come prefisso canonico di amministrazione del CMS e non espone intenzionalmente comportamenti di amministrazione del CMS tramite /admin o /cms.

La direzione obiettivo resta un prefisso di amministrazione del CMS configurabile, con /webadmin come valore predefinito, così che un prodotto host possa mantenere /admin per la propria area amministrativa e gli asset del CMS possano restare sotto /cms.

Finché l'implementazione non sarà allineata, la documentazione e i progetti devono indicare esplicitamente se descrivono il comportamento attuale o l'architettura obiettivo.

• Questo documento non rende il CMS responsabile dell'autorizzazione del prodotto host.
• Questo documento non richiede che i prodotti host dipendano dal CMS.
• Questo documento non implementa di per sé modifiche a rotte o migrazioni.