Non serve reinventare il web per creare un CMS moderno
Le nuove tecnologie Web sono entusiasmanti. Nuovi framework, modelli di rendering, sistemi di costruzione e livelli di astrazione risolvono regolarmente problemi reali.
Ma non tutte le nuove applicazioni necessitano di una nuova architettura applicativa.
WebBlocks CMS è partito da una domanda abbastanza semplice:
Fino a che punto può spingersi un moderno CMS se continuiamo a utilizzare tecnologie web familiari laddove già funzionano bene?
Ciò significa PHP e Laravel per l'applicazione. Un database relazionale per contenuti strutturati. HTML per il markup. CSS per la presentazione. JavaScript laddove il comportamento del browser richiede effettivamente JavaScript.
Nessuna di queste idee è nuova.
Ciò è intenzionale.
WebBlocks CMS non è un tentativo di reinventare MVC, inventare blocchi, sostituire Laravel o introdurre un'altra architettura frontend. È un tentativo di costruire un CMS moderno e capace mantenendo l'applicazione sottostante comprensibile e sotto il controllo dello sviluppatore.
E ciò significa sempre più anche rendere lo stesso CMS strutturato accessibile in modo sicuro agli strumenti di intelligenza artificiale e di automazione.
Un CMS che si unisce all'applicazione Laravel
Un presupposto comune sui CMS è che il CMS sia l’applicazione.
Lo installi, costruisci tutto nel suo mondo, segui le sue convenzioni di routing, usi il suo modello di estensione e adatti il resto del tuo progetto attorno ad esso.
WebBlocks adotta un approccio diverso.
È distribuito come pacchetto Composer e può essere installato in un'applicazione Laravel che già possiedi.
L'applicazione Laravel rimane l'applicazione.
Continua a possedere cose come:
- autenticazione
- configurazione del database
- code
- posta
- distribuzione
- route dell’applicazione
- infrastruttura
- logica di business specifica del dominio
WebBlocks aggiunge il livello di gestione dei contenuti: pagine, layout, blocchi, contenuti multimediali, navigazione, localizzazione, revisioni, flussi di lavoro di pubblicazione e l'area di lavoro /webadmin.
L'installazione rimane volutamente familiare:
composer require fklavyenet/webblocks-cms
seguito da php artisan webblocks:install.
Non è necessario creare una seconda applicazione frontend solo perché il progetto ora necessita di contenuto modificabile.
Il tuo prodotto Laravel e il tuo sito web possono convivere
Ciò diventa particolarmente utile quando il sito Web è solo una parte di un'applicazione più ampia.
Immagina di avere già:
- un prodotto SaaS
- un portale clienti
- un'applicazione di prenotazione
- un sistema aziendale interno
- una piattaforma di appartenenza
- un'applicazione Laravel correlata all'e-commerce
- o semplicemente un progetto Laravel con una sostanziale logica aziendale personalizzata
Il prodotto stesso potrebbe già funzionare perfettamente.
Ciò di cui hai bisogno è un modo in cui gli editori possano gestire la parte rivolta al pubblico: la home page, le pagine dei prodotti, la documentazione, le pagine di destinazione, il contenuto della guida, le pagine legali, le pagine della campagna o altri contenuti editoriali.
Una soluzione è aggiungere un'altra applicazione.
Un CMS separato. Un frontend separato. Forse un altro framework, un altro processo di distribuzione e un altro confine di integrazione tra il prodotto e il sito web.
WebBlocks può invece diventare il sito Web opzionale e il livello di contenuto dell'applicazione Laravel esistente.
La logica del prodotto rimane al suo posto.
In Laravel.
Il CMS gestisce le parti orientate al contenuto.
A questo è destinato il modello di coesistenza .
WebBlocks può anche funzionare come CMS principale per un sito Web convenzionale. Il punto importante è che non forza ogni progetto Laravel nella stessa architettura.
Può eseguire anche il rendering del sito Web pubblico
WebBlocks non si limita a fungere da database del contenuto headless.
Può gestire ed eseguire il rendering del sito Web pubblico stesso.
Le pagine hanno percorsi pubblici reali come:
/features/contact/docs/internal-content-api
Il renderer pubblico funziona dalla stessa struttura strutturata Pagina → Layout → Slot → Modello blocco che gli editor gestiscono nel CMS.
Ciò significa che un'applicazione Laravel può contenere sia percorsi dell'applicazione che pagine pubbliche gestite da CMS senza introdurre un altro runtime frontend esclusivamente per la distribuzione del contenuto.
Il pacchetto CMS stesso non richiede Node, npm, Vite o un framework frontend separato.
Ciò non significa che JavaScript sia vietato.
Significa che JavaScript viene utilizzato quando qualcosa effettivamente necessita di JavaScript anziché essere reso un prerequisito per il rendering del sito Web.
Lo stesso principio si applica a tutto il progetto:
usa ciascuna tecnologia laddove apporta qualcosa di utile.
Pagina → Layout → Slot → Blocco non è una nuova invenzione
I sistemi di contenuti basati su blocchi esistono da molti anni.
Drupal dispone di regioni e blocchi. Altri prodotti CMS hanno le proprie versioni di sezioni, componenti, moduli, widget e contenuti riutilizzabili.
WebBlocks non afferma di aver inventato questo concetto.
Il suo modello di contenuto è deliberatamente comprensibile:
Pagina → Layout → Slot → Blocco
Una pagina seleziona un layout.
Il layout definisce le aree denominate.
Questi slot contengono blocchi.
I blocchi contengono contenuto strutturato e possono essi stessi supportare strutture nidificate ove appropriato.
Il valore non è che le parole siano nuove.
Il vantaggio è che un editor, uno sviluppatore Laravel e uno strumento di automazione possono ragionare tutti sulla stessa struttura esplicita.
Non è necessario che vi sia un modello di applicazione frontend nascosto tra il CMS e la pagina sottoposta a rendering.
Il contenuto riutilizzabile dovrebbe essere normale
Intestazioni, piè di pagina, barre laterali, inviti all'azione e altre strutture ripetute non dovrebbero dover essere ricostruite su ogni pagina.
WebBlocks utilizza Shared Slots per questo.
Ancora una volta, il contenuto riutilizzabile non viene presentato come un'invenzione CMS rivoluzionaria. È qualcosa che un CMS pratico dovrebbe fornire.
Ma il contenuto riutilizzabile introduce anche un importante problema editoriale: la modifica del contenuto condiviso può interessare più pagine contemporaneamente.
Questo è il motivo per cui Shared Slots partecipa ai propri contenuti controllati e ai flussi di lavoro di revisione invece di essere trattati come frammenti globali invisibili.
Il riutilizzo è utile.
Il riutilizzo regolamentato è più sicuro.
La pubblicazione non è solo un interruttore di attivazione/disattivazione
Un CMS diventa più interessante quando più di una persona, o più di un tipo di attore, può modificare il contenuto.
WebBlocks separa lo stato della pagina dalla pubblicazione del blocco anziché presupporre silenziosamente che la pubblicazione di una pagina debba rendere pubblico ogni blocco non pubblicato.
Le pagine possono spostarsi attraverso gli stati editoriali.
Revisions forniscono istantanee di sicurezza a livello di pagina.
Il contenuto condiviso dispone di una propria cronologia delle revisioni.
La pubblicazione può specificare esplicitamente se anche i blocchi di proprietà della pagina devono diventare pubblici.
Questo è importante per i team editoriali umani.
Diventa ancora più importante quando l'automazione e l'intelligenza artificiale entrano nel flusso di lavoro.
Il multisito e la localizzazione fanno parte del modello di contenuto
Un'installazione WebBlocks può gestire siti, domini e lingue distinti mantenendo esplicita la proprietà del sito.
Localizzare non significa semplicemente “duplicare la pagina e tradurla”.
Contenuti, percorsi e dati SEO possono essere localizzati mentre la struttura della pagina revisionata rimane comprensibile.
Ciò diventa utile per le organizzazioni che eseguono diversi siti di prodotto, siti regionali o proprietà multilingue ma non desiderano un'installazione CMS separata per ciascuno di essi.
Ancora una volta, ciò non significa che multisito o localizzazione siano concetti nuovi.
Sono responsabilità CMS stabilite.
L'obiettivo è fornirli senza richiedere all'applicazione Laravel di cedere il controllo della propria architettura.
Anche i media appartengono al CMS
Il contenuto editoriale è più del semplice testo.
WebBlocks include la gestione dei media e varianti di immagini in modo che i media possano partecipare allo stesso ambiente di pubblicazione strutturato delle pagine e dei blocchi.
Combinato con navigazione, ricerca, revisioni, backup, trasferimento di siti e pubblicazione controllata, l'intenzione è quella di coprire le normali responsabilità operative previste da un CMS piuttosto che dimostrare un piccolo prototipo di editor a blocchi.
Questa distinzione è importante.
Un editor di blocchi è una funzione.
Un CMS deve gestire anche il ciclo di vita del contenuto.
Quindi l'intelligenza artificiale cambia il problema
È qui che l'architettura convenzionale diventa particolarmente interessante.
Molti prodotti attualmente aggiungono l'intelligenza artificiale posizionando una casella di testo da qualche parte nell'interfaccia di amministrazione e collegandola a un modello.
Ciò può essere utile, ma non è la direzione che WebBlocks sta esplorando.
La domanda più interessante è:
Cosa succede se uno strumento di intelligenza artificiale è in grado di comprendere e gestire il CMS attuale in modo sicuro?
WebBlocks espone funzionalità CMS strutturate tramite Internal Content API.
Uno strumento operatore o AI affidabile può ispezionare l'installazione effettiva anziché indovinare come funziona il CMS.
Può rilevare siti, impostazioni locali, layout, tipi di blocco e contratti di contenuto disponibili.
Può ispezionare il contenuto strutturato esistente.
Può preparare un intero piano di pagina.
Può convalidare quel piano prima di modificare il contenuto.
Può creare o modificare il contenuto della bozza.
E la pubblicazione rimane una funzionalità separata che richiede un'autorizzazione esplicita.
Questa distinzione è importante.
L'IA non ha bisogno di raschiare l'interfaccia di amministrazione.
Non è necessario simulare i clic del mouse.
Non è necessario inventare l'HTML e sperare che il CMS lo accetti.
Può funzionare con lo stesso modello di contenuto strutturato compreso dal CMS stesso.
L'accesso AI non deve necessariamente significare accesso illimitato
Fornire a uno strumento di intelligenza artificiale l'accesso a un CMS introduce una domanda ovvia:
Cosa è consentito fare?
Internal Content API ha deliberatamente un ambito di autorizzazione.
La convalida del contenuto e l'applicazione del contenuto sono operazioni separate.
L'applicazione del contenuto avviene prima come bozza.
La pubblicazione richiede una funzionalità content.publish separata.
L'API rifiuta le operazioni al di fuori dei contratti definiti anziché trattare l'automazione come un amministratore con libertà illimitata.
L'intento non è:
"Lascia che sia l'intelligenza artificiale a controllare il sito web."
È più vicino a:
"Consenti agli strumenti affidabili di eseguire operazioni CMS ben definite rispettando lo stesso tipo di limiti che ci aspetteremmo da altri attori applicativi."
Ciò crea possibilità interessanti.
Uno strumento AI potrebbe preparare una nuova pagina di destinazione lasciando la decisione finale di pubblicazione a un editore.
Potrebbe aggiornare le sezioni della bozza selezionate senza sostituire l'intera pagina.
Potrebbe comprendere quali strutture a blocchi supporta l'installazione effettiva prima di proporre il contenuto.
Potrebbe funzionare in un sito multilingue rispettando i limiti del sito e delle impostazioni locali.
E poiché si tratta di funzionalità CMS piuttosto che di un'integrazione AI specifica del provider, il core CMS non deve dipendere da un fornitore di modelli.
Convenzionale non significa statico
Utilizzare tecnologie consolidate non significa rifiutare nuove funzionalità.
Può significare collocare tali funzionalità a un livello diverso.
L'HTML non diventa obsoleto perché un'intelligenza artificiale ha contribuito a creare il contenuto.
Non è necessario che Laravel diventi un'applicazione JavaScript perché un editor desidera blocchi interattivi.
Un database relazionale non diventa inadatto perché uno strumento di automazione scrive contenuto strutturato tramite un'API.
Il rendering lato server non impedisce i flussi di lavoro editoriali moderni.
E un'applicazione Laravel convenzionale può ancora esporre contratti leggibili dalla macchina sufficientemente sofisticati da consentire agli strumenti di intelligenza artificiale di funzionare in sicurezza.
Questa combinazione è l'esperimento alla base di WebBlocks CMS.
Ciò che WebBlocks non sta cercando di dimostrare
WebBlocks non sta cercando di dimostrare che:
- MVC è nuovo
- le applicazioni monolitiche sono nuove
- i blocchi sono nuovi
- le regioni riutilizzabili sono nuove
- il rendering lato server è nuovo
- i flussi di lavoro CMS sono nuovi
Chiaramente non lo sono.
Il progetto non sostiene nemmeno che i framework frontend, le architetture headless o le applicazioni con JavaScript siano intrinsecamente sbagliate.
Risolvono problemi reali e sono la scelta giusta per molte applicazioni.
La questione più ristretta è se debbano essere un requisito automatico per ogni progetto Laravel supportato da CMS.
La risposta di WebBlocks è renderli facoltativi anziché fondamentali.
Una base volutamente noiosa
Esiste la tendenza nel software a descrivere la "tecnologia noiosa" come se fosse una scusa.
Può anche essere un vantaggio.
Uno sviluppatore Laravel che apre un progetto WebBlocks dovrebbe comunque riconoscere un'applicazione Laravel.
Uno sviluppatore frontend dovrebbe comunque vedere HTML, CSS e JavaScript.
Un editor dovrebbe visualizzare le pagine e il contenuto anziché l'architettura di distribuzione.
E uno strumento di intelligenza artificiale dovrebbe vedere schemi, autorizzazioni e operazioni strutturate espliciti anziché dover decodificare un'interfaccia di amministrazione.
Al di sopra di queste fondamenta c'è molto spazio per l'innovazione.
La fondazione stessa non deve essere sconosciuta.
Provare l'approccio anziché la terminologia
I singoli concetti in WebBlocks CMS sono intenzionalmente riconoscibili.
La parte interessante è il modo in cui lavorano insieme:
- un CMS Laravel installabile con Composer,
- un livello di contenuto facoltativo per un prodotto esistente,
- il rendering del sito web pubblico,
- pagine strutturate e contenuti riutilizzabili,
- multisito e localizzazione,
- contenuti multimediali e navigazione,
- revisioni e pubblicazione controllata,
- API con autorizzazioni delimitate che consentono agli strumenti IA moderni di partecipare a veri flussi di lavoro CMS.
Se tale combinazione sia utile è una questione molto più interessante rispetto all'esistenza prima di MVC, blocchi o applicazioni monolitiche.
Lo hanno fatto.
Il progetto è open source, la documentazione è pubblica ed è disponibile una dimostrazione dal vivo.
Quindi il modo migliore per valutare l'idea è non chiedere se gli ingredienti sono nuovi.
Prova il CMS e scopri cosa è possibile creare con esso.