Questo articolo potrebbe contenere informazioni interessanti ma non più correntemente aggiornate.
Questi giorni è uscita la nuova major version di WordPress, versione 5.0 nome in codice “Bebo” con importanti novità, in questo post voglio parlarvi delle avventure di coding incontrate durante l’esplorazione del nuovo arrivo.
In WordPress 5.0 vede il debutto il nuovo editor WYSIWYG che ha preso il nome di progetto Gutenberg in fase di sviluppo, decidendo di abbracciare una moderna chiave di editing come già avvenuto attraverso plugin con l’utilizzo di page builders.
Nel nuovo editor è possibile creare dei blocchi di contenuto che possono contenere diversi elementi: paragrafi, colonne con altri blocchi, widget, elementi multimediali, gallerie di immagini, shortcode. In realtà questo è l’inizio di un cambio radicale di approccio nella modalità di editare i contenuti da parte della più popolare piattaforma di blogging, nei prossimi anni il progetto prevede infatti di rivedere Customizer e template delle pagine.
Se da un lato l’introduzione di queste novità sopperisce alla carenza di migliorie nell’editor e dall’altra costituisce un adeguamento alle consuetudini attuali dei publisher, non sono di certo mancate lamentele, tanto da far proporre un fork di WordPress senza Gutenberg.
Appena uscita la release mi sono apprestato ad approfondire due blocchi in particolare: core/columns e core/column, con l’intento di adattarli alle mie esigenze ed aggiungere i nomi delle classi css del framework Bootstrap.
L’editor utilizza la famigerata libreria JavaScript React, sviluppata da Facebook ed utilizzata per il rendering client-side dei post (sfruttando la potenza del browser navigatore anziché le risorse del server ospitante) che vi capiterà di vedere frequentemente se siete utenti dell’arcinoto social network.
Purtroppo le colonne create con il componente core/columns, colonne genitrici e le colonne figlie, componente core/column, non hanno alcun riferimento della propria ereditarietà, questo avviene solo in prima istanza e in determinate circostanze, rendendo inutilizzabile ogni riferimento assegnato alle colonne.
Il primo tentativo è stato quello di sfruttare gli agganci previsti per estendere e filtrare proprietà e funzionalità (hooks e filters) cercando di iterare le colonne genitrici, leggere il numero di colonne figlie e aggiungere i nomi delle classi rispettandone l’ereditarietà. E qui sorge il primo problema, infatti gli elementi di React vengono gestiti e renderizzati in parallelo, in maniera asincrona, non permettendo di intervenire sul DOM nativo prima dell’effettiva iniezione degli elementi nell’editor.
Nel secondo tentativo sempre utilizzando gli agganci e in particolare: editor.BlockEdit blocks.getBlockAttributes blocks.getSaveContent.extraProps blocks.getSaveElement, ho provato a iterare le colonne figlie provando ad estenderne le proprietà (“props” in React) e anche ciò è stato inutile in quanto l’elemento InnerBlocks che è colui che effettivamente contiene le colonne figlie non viene esposto nei filtri.
Terzo tentativo cercando di utilizzare ReactDOM per ottenere le colonne figlie e riassegnarle alle rispettive colonne genitrici, anch’esso reso impossibile dal fatto che non essendo ancora renderizzate non è possibile ottenerle all’interno degli agganci.
Il quarto tentativo che è quello che non avrei sperato di dover fare è stato quello di assegnare degli identificativi univoci ID a tutte le colonne sfruttando la sincronia presente nel momento dell’inserimento delle colonne nell’editor e inserire l’ereditarietà negli attributi degli elementi, questo significa che non è possibile manipolarle al caricamento della pagina poiché vengono restituite a ritroso, partendo per esempio da core/paragraph > core/column > core/columns.
Non so se esista un metodo migliore, nel caso lo conosciate o siate riusciti nell’intento, scrivetemi nella pagina di GitHub del gist: https://gist.github.com/ctlcltd/21ee91114f7b389c995831c8c1aa5c02.
Un’altra via percorribile potrebbe consistere nel registrare due nuovi blocchi columns e column con le stesse identiche funzionalità e ampliandole secondo le proprie esigenze e a quel punto sovrascrivere core/columns e core/column, se fattibile, oppure proponendoli nella select dell’editor prima di quelli inclusi nell’editor, cosa comunque controversa e ambigua per l’utente.
Questo però mi pone un interrogativo su cosa potrebbe diventare la select dell’editor inserendo plugin anche quando non è necessario, per una sciocchezza come l’inserimento di un nome di classe css oppure di altri semplici attributi degli elementi html, tutto ciò contrasta con la notoria estensibilità di WordPress.
Personalmente ritengo che Gutenberg sia una novità straordinaria, forse giunta un po’ in ritardo con i tempi ma comunque necessaria.
Puoi commentare questo post sulla pagina Facebook @loltgt e condividerlo.