Temi a blocchi per WordPress. Il Full Site Editing (FSE)

Il Full Site Editing (FSE) riscrive completamente il modo di creare e utilizzare i temi di WordPress. La struttura dei template rimane invariata, ma il modo con cui essi vengono sviluppati è molto diverso.

Il Full Site Editing, come detto poc’anzi, riscrive completamente il modo di creare e utilizzare i temi di WordPress.

Tutti i template passano da php a html, utilizzando un sistema di server-side rendering dei blocchi che ne definiscono la struttura. I file dei templates vengono quindi salvati nelle directory templates; nella directory parts verranno salvati i parziali quali, ad esempio, header.html e footer.html che vanno a sostituire header.php e footer.php.

Una nuova serie di blocchi dedicati al tema, sarà a disposizione, come quelli per il logo, i menu di navigazioni e perfino un blocco per eseguire queries. Ovviamente viene fornito un nuovo editor che permette di creare e modificare qualsiasi struttura di blocchi all’intero dei template e dei parziali.

Il nuovo editor sostituisce definitivamente l’amato e odiato Customizer.

Ultimo punto, ma non per importanza, è l’introduzione del file theme.json. Questo file ricopre un ruolo chiave poiché contiene tutte le informazioni sugli stili e sulle funzionalità del tema.

Utilizzare un tema FSE su WordPress vuol dire avere a che fare esclusivamente con Gutenberg per creare l’intera struttura del sito, arrivando a definire l’aspetto e il risultato delle query visualizzate sia negli archivi che nel sito.
Anche header e footer, vengono gestiti con dei blocchi. È possibile creare, ad esempio, sidebar diverse e importarle nei template. Il tutto grazie ad un nuovo set di blocchi creati su misura.

La necessità di dover mettere mano al codice si riduce drasticamente se si lavora su un tema proprietario, tendendo poi ad azzerarsi se si lavora su dei temi già pronti e disponibili nella repository di WordPress.

La gestione dei contenuti risulta molto più facile, permettendo di intervenire facilmente su tutti quegli aspetti che prima rendevano necessario dover mettere mano al codice.

I vantaggi sono:

• la possibilità di costruire gran parte di un tema senza dover mettere mano al codice per definire la struttura dei template;
• poter utilizzare la feature di ripristino del template in caso di manomissione, la quale andrà a recuperare il file .html salvato nella directory del tema che non viene sovrascritto quando l’utente esegue modifiche con Gutenberg.

La mancanza di alcune caratteristiche che sono basilari per un sito web al giorno d’oggi.

Su tutti, la mancanza di gestione del responsive, questo problema è circoscritto ai blocchi del core. Infatti, utilizzando altre librerie di blocchi il problema viene risolto facilmente, in quanto quasi tutte permettono, ad esempio, di modificare gli spazi bianchi in base alla viewport.

Più impegnativa invece la gestione delle query. Se a colpo d’occhio il blocco dedicato alle query sembra essere fatto veramente bene, iniziando a popolarlo si scoprono i limiti dettati dal non poter riprodurre strutture complesse con uno strumento progettato per essere semplice.

Il blocco query mette a disposizione un paio di layout (a card o in lista) e il template di visualizzazione del post è facilmente editabile, ma quando dobbiamo iniziare a inserire elementi aggiuntivi, come ad esempio i campi personalizzati – per i quali ad oggi non ci sono ancora blocchi per integrarli – o a gestire i layout in modo che rispondano in diversa maniera su più viewport, ecco che dobbiamo arrenderci e tornare alle vecchie soluzioni a codice.

Ultimo aspetto, ma non per importanza, è la gestione di più pagine con lo stesso layout e contenuto diverso.

È certamente possibile utilizzare un blocco riutilizzabile per costruire il layout della sezione, ma si andrà a perdere la possibilità di propagare le modifiche nel momento in cui si personalizza il contenuto. Per applicare il nuovo layout di sezione, in seguito alla pubblicazione, sarà necessario replicare tutte le modifiche su tutti i post pubblicati dove è questa è presente. Decisamente scomodo, soprattutto con l’aumentare del numero dei post del sito.

Sulla base di tutte le considerazioni, degli svantaggi e dei vantaggi arriviamo alle conclusioni.

Ad oggi, con la major 5.9 – è la versione 13. del plugin Gutenberg che diventa praticamente d’obbligo per avere il pieno controllo, il Full Site Editing è pronto per essere usato in produzione ma esclusivamente su siti di piccole o medie dimensioni, come:

• landing pages
• siti di presentazione con poche variazioni di template e ben definiti, senza un catalogo
• blog con idee ben chiare sul layout, sulla gestione dei contenuti e pochi contenuti.

Un utilizzo su siti più complessi, ad esempio con un catalogo e con layout ricchi e complessi, oppure su siti con una notevole quantità di contenuti è assolutamente prematuro e richiederebbe integrazioni specifiche. La mancanza di un controllo capillare sulle versioni responsive e sui layout dei contenuti, rende estremamente difficile l’adozione su una platea più estesa di siti, inclusi gli e-commerce.

1. Ollie
2. Spectra One
3. Frost
4. Neve FSE
5. Bricksy
6. Gutenify
7. Raft
8. UniBlock
9. YITH Wonder
10. Basti
11. Björk
12. GreenShift