Tutti voi sapete che è arrivato Gutenberg su WordPress. Potremmo riassumere il tutto con una frase: “L’idea è buona, ma così non avrà successo”.

Sono uno sviluppatoredi temi fin dalle prime versioni di WordPress, sviluppo plugin professionali e nella mia esperienza non ho usato solo WordPress, ma anche sistemi CMS come Strapi.io, o sistemi serverless come Hugo scritto in Go. Li ho provati e testati.

Ma oggi mi sento di dire la mia su questa scelta sbagliata che la community di WordPress ha scelto.

Pregi di Gutenberg

• mi piace il fatto che ci sia un editor che è modulabile nel suo contenuto, i blocchi sono comodi da spostare
• Ci sono molte opzioni personalizzabili per ogni singolo blocco
• E’ facile trovare dei blocchi grazie all’interfaccia di ricerca
• Ci sono i patterns! Questi molto comodi per creare al volo pagine in pochi click
• Carina la gestione del file theme.json che racchiude tutte le variabili globali per l’editor

Difetti di Gutenberg

Acerbo nella gestione di temi, menu o widgets. A volte si perde molto tempo solo per spostare 2 voci

Qui un esempio di come si accavallano le voci quando si tenta di inserire una sottopagina.

Si è legati molto al template e fare modifiche non è cosi immediato, i files sono in html e non si può usare PHP, o condizionali comodi che esistono nel core di WordPress.

I patterns

Belli, ma non possono essere aggiornati dagli sviluppatori. In pratica quando create un pattern e lo inserite nel vostro sito, questo rimarrà cosi per sempre e anche se il tema si aggiorna e cambia qualcosa al pattern che lo sviluppatore aveva scritto, il vostro vecchio pattern inserito non si aggiorna.

Il senso di questa cosa è quasi indicibile.

I temi

Realizzare un tema prima era più facile. Bastava prendere un file header.php e metterci li il codice desiderato.

Nei temi a blocchi ora dovete creare un file header.html dentro la cartella parts, ma non potete metterci del codice extra, perché viene interpretato male dall’editor nel wp-admin. Nemmeno uno <span>

Il codice CSS viene messo inline. Difficile quindi da sovrascrivere tramite files .css o altro. E vai di !important…

I blocchi

Per realizzare un blocco personalizzato, dovete creare un plugin a parte, dovete avere conoscenze medie di React, nozioni di NPM, di comandi da terminale, JS e concettuali ad oggetti.

La parte che mi preoccupa di più è quella della manutenibilità del codice nel tempo. I vecchi template bene o male non davano problemi e non lo daranno nemmeno i nuovi probabilmente, ma i problemi li daranno gli “enviroments” cioè obbligare costantemente lo sviluppatore a restare aggiornato non solo sul codice, ma anche sul sistema di base per la compilazione del codice, quindi updates per node js e vari pacchetti.

I sistemi a volte si rompono e non è facile andare a riprendere un codice dopo 2-3 anni e dover rivedere le parti e riscriverle per i nuovi updates, affiché il vostro pc riesca a interpretarla. Tempo veramente perso.

Curva di apprendimento

Passare da PHP a JS senza una via di mezzo è la rovina, significa buttare anni di studi e professionalità per intraprendere una strada nuova, piena di ostacoli e con una documentazione praticamente inesistente.

I comuni mortali non potranno mai riuscire a personalizzare un template.

Aggiungo inoltre che per creare un blocco da zero bisogna perderci almeno 8 ore di sviluppo per un blocco poi tutto sommato semplice, con del testo e 1 immagine. Se volte realizzare qualcosa di più complesso ci vogliono settimane.

Prima in 4 ore si riusciva a fare la stessa identica cosa. Pensate ad un semplice slider e provate voi a realizzarlo nel vecchio modo, con php e ACF per esempio e poi provate a farlo con il codice a blocchi di Gutenberg. Ci vogliono almeno 48 ore di sviluppo per la stessa identica cosa.

Si avrete una interfaccia migliore lato admin ma lato front-end non cambierà assolutamente nulla.

I tempi di sviluppo

Il tempo è denaro. Se lavorate da soli o per una azienda il tempo è quello che conta di più! Il fatto di dover perdere 1 ora di tempo solo per ricrear un eviroment e interfacciare il tutto con GIT e poi scrivere le prime righe è estenuante.

I template sono castrati, devi mettere del codice inline, non puoi aggiornare i patterns nel tempo e comunque non puoi usare php condizionale all’interno dei file .php.

A mio parere WP ha fatto la scelta sbagliata, ma attenzione! non tanto per i blocchi all’interno dell’editor, quelli sono comodi, semmai, ha sbagliato l’approccio con i temi e la personalizzazione interna. Ricordate il vecchio Customizer? Ora morto e sepolto, nemmeno il tempo di fargli fare 3 anni.

Per questo ho paura. Ho paura che facciano la stessa cosa con Gutenberg e il sistema a blocchi, cambiando di nuovo metodologia e obbligandovi a dover studiare tanta, tanta teoria, quando quello che ci piace fare, come DEV è far funzionare le cose e ottenere risultati!

WooCommerce

Ho provato e testato i nuovi blocchi sia per il carrello che per la sezione pagamenti del sito. Che dire, bellini si, ma alla fine anche qui dovete usare JS per la modifica di una singola parte e udite udite… ci ho provato ed è possibile farlo si, ma…. solo su alcune parti e non potete toccare nemmeno una linea di html… inconcepibile per un e-commerce al giorno d’oggi.

Date pure una occhiatina qui: https://github.com/woocommerce/woocommerce-blocks/blob/trunk/docs/third-party-developers/extensibility/checkout-block/available-filters.md