Introduzione al Full Site Editing di WordPress

La storia di WordPress è fatta di costanti aggiornamenti e un costante lavoro di implementazioni, novità, cambi di rotta, migliorie e, ovviamente, qualche passo falso. Del resto, neanche il cms più utilizzato al mondo, è esente da bug ed errori. Nel 2018, con il rilascio di WordPress 5.0, viene introdotto il nuovo editor, al secolo Gutenberg, che va a sostituire il noto Classic editor, cambiando di fatto l’intera esperienza nella creazione dei contenuti (e non solo) di un sito web, si passa dalla semplice gestione di testi e immagini alla gestione di interi blocchi di layout. Il piano è quello di giungere alla versione 6, prevista presumibilmente per l’estate del 2022, con un’esperienza di creazione sempre più simile a quella offerta dai page builder ma nativa, ovvero, perfettamente integrata nel core.

Differenza tra un tema a blocchi classic e un tema FSE

Il 25 Gennaio 2022 viene rilasciato WordPress 5.9, il Full-Site Editing fa la sua prima apparizione ufficiale tra noi. Di cosa si tratta? Semplicemente non più di costruire il sito sfruttando le caratteristiche di un tema e i blocchi per i layout interni ma bensì la possibilità di creare l’intero sito utilizzando solamente i blocchi. In parole povere, per chi un pò è sgamato sull’argomento, potremmo dire che un tema classico che supporta Gutenberg è sulla linea di Elementor free, posso fare cose ma dipendo dal tema, mentre un tema FSE mi permette di avere un’esperienza simile a quella fornita da Elementor Pro con il suo tema Hello (lo so che il paragone regge fino ad un certo punto ma serve solo per darvi un’idea).

Quindi, con FSE, possiamo gestire aree del sito che prima erano ad uso e consumo del tema, di widgets o customizer come Header, Footer, Nav, il logo, ecc. In questo momento ci troviamo in una situazione dove abbiamo a disposizione entrambe le opzioni, la gestione è pertanto definita dal tema e se questo supporta FSE oppure no. Questa possibilità di scegliere è ottima soprattutto per il fatto che pare questa nuova esperienza non sia stata accolta con troppo entusiasmo dai themes developers, sono davvero pochi infatti i temi presenti nella repository a supportare questa novità per i più svariati motivi: metodo ancora acerbo, tempi di realizzazione lunghi, difficile da portare in un sito in produzione, troppi cambiamenti e poche certezze, il rischio di lavorare e dover continuamente rimettere mano è ben visibile già partendo dal presupposto che, nel nuovo editor, viene indicata la scritta beta.

Hybrid themes, cosa sono?

Un concept che trovo molto interessante, e di cui ho visto qualcosina in giro, è l’opzione del tema ibrido, ovvero la possibilità, in un unico tema, di switchare tra la gestione FSE e la semplice gestione di Gutenberg in modalità blocchi di layout. Esistono alcuni temi online a supportare questa funzionalità, gestita attraverso il file .json, ma ad oggi nessuno di questi è presente (che io sappia) nella repository ufficiale di WordPress. Sono molto incuriosito da questa possibilità e, se un giorno venisse sdoganata, mi piacerebbe implementare questa funzione nel mio tema Sensei S2.

Nel momento in cui scrivo sono solamente 47 i temi FSE presenti in repository, Matt Mullenweg, a quanto ho potuto leggere in un articolo di cui non posso lasciarvi la fonte perché non la ricordo, pare se ne aspettasse almeno 5k. Insomma, come già ribadito, l’accoglienza è stata un pò freddina ma si continua ad invitare gli sviluppatori di temi a buttarsi su questo nuovo metodo. Da sviluppatore di temi, ad oggi, non trovo un motivo valido per doverlo fare ma non escludo che in futuro prenderò in considerazione questa possibilità.

La domanda che mi pongo è: ma un’azienda ha davvero bisogno di avere tutte queste funzionalità nel sito alzando di botto il rischio di sminchiarlo? Un web designer che lavora con un metodo classico ha davvero bisogno di queste funzionalità e dipendere cosi tanto da Gutenberg? La risposta che mi sto dando al momento è no ma, ovviamente, dovremo vedere come si evolveranno le cose e solo gli stupidi non cambiano mai idea.

Anatomia di un tema FSE

Bando alle ciance e andiamo finalmente a vedere come è strutturato un tema FSE. Premetto che, per avere una minima comprensione dei contenuti a seguire, sarebbe utile avere competenza nella creazione di temi custom o perlomeno della gerarchia dei template e dei file di prima, seconda, terza parte o statici che un tema utilizza.

In un classic theme, con supporto o no a Gutenberg, tutta la struttura viene gestita da dei file .php, nella tradizionale metodologia di scrittura di un sito modulare. La gerarchia dei template viene basata quindi su file che il core riconosce automaticamente in base alla richiesta fatta, esempio, il file single.php per gli articoli o il file page.php per le pagine. Il file functions.php determina le regole, le funzionalità, il supporto, la comunicazione tra il tema e il core del back-end attraverso gli hooks (la sto facendo semplice) mentre lo style.css determina lo stile grafico. Tutto il resto viene gestito attraverso funzioni php ad hoc di WordPress come ad esempio the_title per i titoli o the_content per i contenuti del layout, funzioni inside o outside loop.

In un tema FSE i file .php lasciano il posto, e la cosa mi ha stupito molto inizialmente, a dei semplici file .html che ricoprono, grosso modo, le stesse funzioni. Vediamoli nel dettaglio presupponendo il più basico dei temi.

index.php – Un file vuoto che fa da switch verso il file predefinito dal tema
style.css – Il foglio di stile generale del tema
functions.php – Il setup del tema, come nei temi classici
theme.json – Un file che si occupa delle configurazioni opzionali di default del tema (opzionale)
screenshot.png – Immagine di anteprima 1200×900

Templates and template parts

Come vedremo nella foto a seguire, oltre ai già citati, troveremo anche una serie di cartelle con altri file, vediamo nel dettaglio anche questi.

templates

index.html – Il primary template che va a sostituire il file index.php dei temi classici per la creazione di post e page
404.html – Il template per il not found
archive.html – Il template per gli archivi
page.html – Il template per le pagine
single.html – Il template per gli articoli

Giusto per citarne alcuni, di fatto possiamo avere tanti template .html quanti necessari come prima facevamo nella root principale del tema classico, la gerarchia rimane tale e quale.

template-parts

header.html – Il template per la gestione di header
footer.html – Il template per la gestione del footer

Anche in questo caso vanno a sostituire header.php e footer.php, secondary template dei temi classici, citiamo questi che sono i principali ma potremmo averne altri all’esigenza.

assets (opzionale)

In molti temi visionati ho visto utilizzare questa cartella per inserire fogli di stile extra, immagini statiche o file js che sono prettamente vincolati al tema. Di fatto, trattandosi di un semplice collegamento, mi sento di definire opzionale questa cartella, potremmo non avere queste esigenze o semplicemente definire un nome differente alla cartella a dispetto delle 2 precedenti.

Il codice in un tema FSE

Mentre in un classic theme, all’interno dei file .php, andiamo a scrivere le varie funzioni che si interfacciano con i vari marcatori che compongono il layout della struttura, nei temi FSE non ci è permesso scrivere (ovviamente) codice php dal momento che i file sono in estensione .html, pertanto le funzioni vengono sostituite da dei commenti condizionali. Per meglio comprendere vediamo un paragone tra le due modalità richiamando nuovamente la funzione per il titolo della pagina e per il contenuto.

In un classic theme avremo la funzione the_title(); per richiamare il titolo di una pagina o di un post
In un tema FSE scriveremo il seguente commento wp:post-title /
In un classic theme avremo la funzione the_content(); per richiamare il contenuto di una pagina o di un post
In un tema FSE scriveremo il seguente commento wp:post-content /

Cosa cambia nell’editor back-end?

Punto premettendo che questo articolo non vuole e non può essere in alcun modo esaustivo in merito, la prima cosa che balza agli occhi è la mancanza delle sezioni dedicate a widgets, menu e customizer dal momento che, queste dinamiche, vengono demandate ai blocchi di riferimento.

Nella mia attuale breve esperienza con i temi FSE, ed essendo da sempre abituato a scrivere codice, ho trovato questa modalità di creazione estremamente noiosa. Del resto, non ho mai gradito ne l’utilizzo di page builder esterni ne tantomeno di temi pro.

La gestione editor risulta completamente differente e ci porta verso sezioni dedicate alle gestione e creazione dei primary template, da una parte, e dei secondary template, da un’altra. Trovo notevoli differenze nell’utilizzo pulito di WP 5.9 senza ausilio di Gutenberg come plugin esterno e lo stesso attivando il plugin. Ovviamente siamo in piena fase beta e agli esordi di questa metodologia ci sarà, pertanto, tutto il tempo di approfondire dove andremo a parare. Anche per questo ritengo superfluo al momento andare oltre una prima comprensione del tutto.

Una grossa parte del lavoro è attribuibile al file .json, molto importante infatti è comprenderne le dinamiche per una migliore gestione delle personalizzazioni che vogliamo dare al tema.

In conclusione

Creare un tema FSE non rientra al momento nelle mie priorità, rimango dell’idea che la soluzione migliore sia mantenere entrambe le possibilità. Sicuramente l’evoluzione del cms è necessaria per stare al passo, per coinvolgere sempre più utenti all’utilizzo, ma non vedo ad oggi un motivo valido, per questioni già citate, perché una web agency o un freelance dovrebbero buttarsi su questa metodologia di lavoro abbandonando i loro temi starter, pro o page builder preferiti.

Sono un sostenitore di Gutenberg dagli esordi ma la direzione intrapresa non è attualmente nelle mie corde, forse lo diventerà forse no, non ho visto comunque al momento grande entusiasmo da parte di colleghi, anche illustri, per la cosa. Rimane un punto fermo, un sito web può essere fatto con qualunque piattaforma, a codice, o qualsiasi approccio riteniate utile alla vostra causa ma non sarà mai il mezzo a fare la differenza bensì le competenze di chi lo guida.

Lascio di seguito un paio di link ad articoli che mi sono stati utili nel primo approccio e, nel caso, vogliate imbarcarvi nella creazione/comprensione dei temi FSE

e 3 video del mio canale dove entro nel merito

See you next time.

Categorie

Guide utili e tutorial

Tag Full Site Editing, Web Design, Web development, WordPress