Benvenuto WordPress 5, benvenuto Gutenberg

E’ finalmente arrivata quella parte dell’anno che ogni sviluppatore ama ed odia, dato che il rilascio di una nuova major release porta novità nel fronte dello sviluppo e dell’organizzazione applicativa (e quindi… felicità!), ma comporta ulteriore studio del sistema in questione, e sicuramente saprete che con le chiusure aziendali natalizie viene difficile pensare di potersi permettere un reale approfondimento del tema.
Con questo piccolo contributo alla causa, cercheremo di smarcare con semplicità le novità che vengono offerte da WordPress 5, più in particolare dal nuovo editor Gutenberg che va a sostituire il vecchio editor WYSIWYG.

Benvenuto Gutenberg

Dicevamo… Gutenberg è il nuovo editor che è già integrato in tutte le nuove versioni di WordPress, successive alla versione 5.0.0.
Dopo aver rilasciato da un paio d’anni un plugin dal nome analogo, per permettersi di testare un’idea e tutte le funzionalità ad essa legate, il plugin è stato integrato in core di WordPress. Ma… come funziona in parole spicce?

Benvenuti blocchi

E’ molto probabile che con l’avvento dei compositori visuali, gli stessi sviluppatori in Automattic abbiano sentito il bisogno di esporre alla comunità un metodo di inserimento dei contenuti che fosse più facile, divertente, snello che il solito e vecchio editor.

Ogni pezzo di contenuto ora può essere visto come un semplice blocchetto che fa esattamente una cosa specifica. Esistono blocchi per inserire un nuovo titolo, un nuovo paragrafo, una nuova immagine o galleria, una nuova lista, un nuovo video embedded (non li citerò tutti, sarebbero troppi). Persino uno spazio vuoto di altezza 30px è diventato un blocco, addio caro css, addio padding!

Ora, sarà molto più semplice per l’utilizzatore finale capire come inserire un titolo, un elenco, senza mandar fuori di testa noi poveri sviluppatori, che ci dovremo occupare solo ed esclusivamente (finalmente) di stilizzare qualcosa di già generato dal sistema. Quindi, addio classi css, addio bug frontend, addio clienti che ti chiamano per sistemare un colore. Ora è già tutto pronto all’uso. Ora un documento non sarà più semplice html, sarà astratto ad un livello superiore e strutturato.

TL;DR: Blocchi come Custom Post Types, commenti HTML come descrittori di blocco

Se non siete nel settore dello sviluppo, ma siete semplici persone curiose del mondo WordPress, potrete saltare questa sezione.

Come funziona tecnicamente questa cosa dei blocchi?
Un blocco è registrato a sistema come una nuova entità, come lo sono un Custom Post Type e una Taxonomy. La differenza in registrazione tra un blocco e un CPT/Taxonomy è che i nuovi blocchi interagiscono con il backend tramite javascript, che ne può dinamicizzare il contenuto al volo. E’ necessario quindi operare in entrambi i linguaggi PHP e Javascript (le guide ufficiali parlano di standard Javascript ES6, armatevi quindi di pazienza e, nel caso vi servissero informazioni su come registrare nuovi blocchi, date un’occhiata al tutorial ufficiale reperibile qui).
Quando un utente inserisce un nuovo blocco in interfaccia backend, il motore javascript di Gutenberg crea un nuovo elemento JSON che viene concatenato all’albero di elementi della pagina in costruzione, che descrive esattamente il medesimo blocco. Ne descrive quindi il contenuto e la formattazione.

[
    {
        type: "core/cover-image",
        attributes: {
            url: "my-hero.jpg",
            align: "full",
            hasParallax: false,
            hasBackgroundDim: true
        },
        children: ["Gutenberg posts aren't HTML"]
    },
    {
        type: "core/paragraph",
        children: ["Lately I've been hearing plen…"]
    }
];

Al salvataggio della pagina, il sistema salva in database, al posto del vecchio e puro HTML in colonna post_content, un insieme di blocchi rappresentati ognuno da un commento html. In base alla tipologia del blocco (se popolato staticamente o dinamicamente), viene appeso un array serializzato contenente le descrizioni del blocco in questione. Questa sotto è la risultante contenutistica della pagina che state leggendo.

Naturalmente, in frontend i commenti sarebbero inutilizzabili, come per l’array descrittivo serializzato… il browser interpreta solo HTML. Esiste quindi un parser che intepreta ogni commento HTML e converte i dati esistenti nell’array di configurazione del blocco in dati che abbiano un senso valido alla visualizzazione in frontend dello stesso.