Come WebBlocks CMS gestisce le risorse frontend

WebBlocks CMS fornisce i CSS e JavaScript richiesti dall'area di lavoro di amministrazione e dai renderer pubblici come risorse del pacchetto pronte per l'uso.

La versione CMS contiene i file del browser. Il programma di installazione li pubblica nella directory pubblica dell'applicazione host Laravel, dove il server web li serve come file statici.

WebBlocks CMS include e mantiene il proprio runtime JavaScript come parte del rilascio del pacchetto.

WebBlocks CMS separa le risorse del browser in tre livelli di proprietà espliciti:

1. Le risorse principali del CMS risiedono in public/cms e cambiano con la versione del CMS.
2. Le sostituzioni a livello di sito si trovano in public/site/{site_handle}/css/site.css e public/site/{site_handle}/js/site.js.
3. Le risorse a livello di pagina possono fare riferimento a CSS o JavaScript locali /site/... approvati per un'esigenza specifica della pagina più ristretta.

I percorsi rendono visibile la proprietà. Un file sotto /cms appartiene alla versione del prodotto. Un file sotto /site/{site_handle} appartiene a quell'installazione e a quel sito.

WebBlocks CMS mantiene le risorse runtime di proprietà del CMS nello spazio dei nomi public/cms. Il programma di installazione del pacchetto e il tag di pubblicazione webblocks-cms-assets copiano le risorse tracciate del pacchetto nella root del documento pubblico dell'host.

Gli stili di amministrazione, gli stili di rendering pubblico, le risorse del marchio del prodotto e i comportamenti JavaScript mirati appartengono alla versione CMS che li utilizza. Vengono rilasciati e testati con il codice PHP.

Gli URL pubblici rimangono URL statici ordinari. Laravel non ha bisogno di eseguire lo streaming di ogni foglio di stile o script tramite un controller. Il server web può servire direttamente i file esistenti, mentre Laravel gestisce i percorsi delle applicazioni.

Ciò spiega anche perché /cms è uno spazio dei nomi di asset anziché un percorso di amministrazione. L'interfaccia operatore si trova sotto /webadmin; mantenendo separata la proprietà del percorso e quella del file system si evitano le collisioni try_files nelle distribuzioni comuni di Nginx.

WebBlocks CMS fornisce un confine di estensione separato per le regolazioni visive di proprietà dell'installazione.

Le impostazioni del blocco nativo e i token WebBlocks UI gestiscono la presentazione ordinaria. Le sostituzioni del sito sono riservate alla composizione specifica dell'installazione che appartiene a quel sito.

La ripubblicazione delle risorse CMS sostituisce i file di proprietà del pacchetto preservando le sostituzioni di proprietà del sito. Le correzioni al core CMS vengono fornite tramite le versioni CMS.

WebBlocks CMS fornisce JavaScript per i flussi di lavoro di amministrazione e il miglioramento progressivo pubblico.

L'HTML con rendering del server rimane la linea di base. Gli script mirati migliorano la navigazione, la visualizzazione dei contenuti multimediali, la ricerca, le modalità e i flussi di lavoro di modifica. I file JavaScript denominati vengono caricati con defer; i renderer pubblici non nascondono il bootstrap dell'applicazione all'interno di script inline arbitrari.

Il processo di rilascio WebBlocks CMS possiede la compatibilità del browser, l'accessibilità, l'ordinamento delle risorse, l'invalidazione della cache e le interazioni tra tali script.

WebBlocks CMS versioni delle risorse rivolte al browser in modo che i file memorizzati nella cache rimangano aggiornati.

I layout CMS aggiungono un valore di versione agli URL delle risorse di proprietà del pacchetto, generalmente in base all'ora di modifica del file installato. Le risorse di sostituzione a livello di sito utilizzano un hash di contenuto. Quando un file cambia, il suo URL cambia in modo che il browser richieda la nuova rappresentazione invece di riutilizzare una copia memorizzata nella cache non aggiornata.

Il pacchetto aggiunge inoltre il runtime WebBlocks UI a un percorso locale con versione. Il browser non necessita di una CDN attiva di terze parti per eseguire il rendering dell'interfaccia CMS e la versione CMS identifica la versione dell'interfaccia utente con cui è stata testata.

Un modello di asset spediti attribuisce al rilascio CMS responsabilità concrete:

• le modifiche sorgente devono essere registrate come file runtime verificabili;
• il processo di rilascio deve verificare la presenza di ogni risorsa necessaria;
• gli aggiornamenti del pacchetto devono sincronizzare le copie runtime in modo sicuro;
• le personalizzazioni frontend approfondite richiedono contratti espliciti per override o plugin.

Per il core WebBlocks CMS, la compatibilità del browser e la completezza delle risorse appartengono alla versione del pacchetto. La presentazione specifica del sito rimane di proprietà dell'installazione e separata dal nucleo CMS.

Quale parte del limite della risorsa vorresti controllare per prima: pubblicazione, invalidamento della cache o sostituzione del sito?