Il Full Site Editing ha iniziato a far parlare di se da metà del 2021 – ma per gli appassionati da molto prima. È una funzionalità inclusa a partire dalla versione 5.9, e se dovessi dare una spiegazione rapida ed essenziale direi che il suo scopo è estende rel’uso di Gutenberg all’intera struttura del sito.
Come ci si può immaginare, il Full Site Editing (FSE, abbreviato) è molto più complesso concettualmente. Fa’ infatti parte della seconda di quattro fasi evolutive di WordPress. È un profondo cambio di paradigma nell’esperienza di gestione dei contenuti tale da renderla, a mio parere, molto familiare per coloro che sono abituati a lavorare con software low-code e no-code.
Procediamo per punti e vediamo insieme cos’è cambiato e se vale la pena investire nell’adozione del Full Site Editing di WordPress.
Cos’è il Full Site Editing
Il Full Site Editing, come detto poc’anzi, riscrive completamente il modo di creare e utilizzare i temi di WordPress. Se da una parte la gerarchia e la struttura dei templates rimane invariata, il modo con cui essi vengono sviluppati è molto diverso.
A prima vista notiamo subito che 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.
Vengono quindi messi a disposizione una nuova serie di blocchi dedicati al tema, 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. Quest’ultimo manda definitivamente in pensione 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. Molti degli add_theme_support a cui eravamo abituati, infatti, vengono inglobati nella struttura del file JSON. Nella versione 2 di theme.json, a disposizione a partire dalla major 5.9 in poi, vengono estese le impostazioni configurabili sia per il tema globale che per i singoli blocchi.
FSE, pro e contro
Pro
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 in giro nel sito.
Anche i parziali, come l’header e il footer, vengono gestiti con dei blocchi. Così, nello steso modo a cui eravamo abituati in fase di sviluppo, con Gutenberg è possibile creare diverse declinazioni dei parziali (ad esempio sidebar diverse) e importarli 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. Anche lo sviluppo ne beneficia, in particolar modo il file theme.json è studiato apposta per evitare ridondanze di codice e negli stili, prima molto frequenti anche a causa della possibilità di mettere mano ai CSS dal Customizer, comportando non pochi grattacapi nel corso del tempo.
È importante far notare che, tramite Gutenberg, i file dei template e dei parziali, una volta modificati, non sovrascrivono quelli originali all’interno del tema. Attraverso l’edito è possibile esportare tutti i template in archivio .zip. I vantaggi diretti sono:
- la possibilità di costruire gran parte di un tema senza dover mettere mano al codice per definire la struttura dei template e dei parziali, importando infine la versione ufficiale nella cartella del tema prima del rilascio;
- 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, come spiegato pocanzi, non viene sovrascritto quando l’utente esegue modifiche con Gutenberg.
A conti fatti, uno dei maggiori vantaggi è il fatto di non dover necessariamente sviluppare un tema a blocchi per poter beneficiare di alcuni vantaggi (come appunto il theme.json) del Full Site Editing. Ad oggi ho avuto modo di provarlo in alcuni temi “misti” permettendomi di scrivere comunque meno codice e rendendo il tema più ordinato e mantenibilie nel tempo.
Contro
Oltre a lavorare su temi misti, ovvero prendendo quanto di più utile dal FSE e dai temi legacy e combinandoli, ho lavorato anche a progetti per il quale è stato scelto di utilizzare esclusivamente il FSE. Fin da subito ho sentito l’atrito generato dalla mancanza di alcune caratteristiche che sono basilari per un sito web al giorno d’oggi.
Su tutti, la mancanza di gestione del responsive.
Premetto che, dato per assunta la definizione di responsive e la differenza con il design adattivo, 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ù lavoro richiede 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.
La mia tecnica preferita, come credo per tantissimi sviluppatori, è quella di creare blocchi custom con ACF, per le query personalizzate. Inoltre questa tecnica, applicata ad una WP_Query, mi permette di controllare meglio i parametri della query stessa, cosa non del tutto possibile con il blocco dedicato.
Ultimo aspetto, ma non per importanza, è la gestione di più pagine con lo stesso layout e contenuto diverso.
Dall’adozione di Gutenberg nel 2018 ad oggi, sono state introdotte molte funzionalità che aiutano a inserire e gestire i contenuti del sito, come i pattern, per importare velocemente strutture grafiche di blocchi già predisposte, e i blocchi riutilizzabili, concettualmente dei veri e propri parziali che ripetono il contenuto e per i quali basta aggiornare l’elemento principale per vedere le modifiche propagate ovunque il blocco venga importato.
Dalla parte contraria, invece, non esiste un sistema che permette di controllare l’output del contenuto nei template in modo centralizzato. Poniamo un esempio pratico: può succedere di voler modificare l’aspetto di una sezione all’interno del contenuto di un post che mostra dei contenuti presonalizzati su un layout predefinito – nel caso dell’immagine seguente è un banner con un bottone call-to-action.
È 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.
Ne vale la pena?
Sulla base di tutte le considerazioni, degli svantaggi e dei vantaggi arriviamo alle conclusioni. Non ti dirò il classico “dipende”, elusivo tanto quanto snervante, ma ti darò il mio parere professionale.
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.
Conclusioni
Ovviamente questa non è una critica al team di WordPress, anzi. Hanno fatto (e continuano) a fare un lavoro pazzesco per il quale dobbiamo ringraziare tutti quegli sviluppatori che stanno mettendo anima e cuore su questo progetto. È scontato che un progetto, iniziato da così poco e con ambizioni così grandi, necessiti di tempo e perfezionamenti per arrivare a rispondere alle tutte le richieste.
Laddove è possibile, l’uso del Full Site Editing può veramente snellire i tempi di sviluppo e rilascio, abbassando la difficoltà richiesta per realizzare prodotti “su misura”.
Il vero aiuto, ad oggi, del lavoro fatto su Gutenberg e sul Full Site Editing, deriva dall’integrazione con la struttura classica dei temi realizzati. Ecco, dunque, che l’uso di soluzioni miste come ad esempio il file theme.json in associazione ai blocchi Gutenberg con ACF e ai classici template in PHP, permette di ereditare tutti i vantaggi di ognuna delle modalità di sviluppo e realizzare progetti di grandi dimensioni risolvendo molti dei più comuni problemi per entrambe.
Lascia un commento