WordPress è ancora una piattaforma affidabile?

Nelle ultime due principali release, la 5.9 e la 6.0 sono state introdotte diverse nuove funzionalità legate al block editor ed è stato rilasciato ufficialmente il Site editor purtroppo però l'approccio alla retro compatibilità del codice mi sembra sia stato perso di vista.

WordPress di per sé si è dimostrato sempre abbastanza affidabile, se parliamo del core in linea di massima è possibile aggiornarlo senza particolari problemi, con l'introduzione del Block editor però si è generata una sensibile e preoccupante instabilità, da qualche release a questa parte, che rende poco prevedibili gli aggiornamenti su progetti custom.

Passando oltre l'inconsistenza delle opzioni di configurazione dei blocchi e alla inadeguatezza della sidebar a gestire le innumerevoli opzioni di configurazione, ci sono un paio di scelte, in qualche modo collegate, che ritengo proprio sbagliate, posso comprenderle ovviamente, ma rimango dell'idea che siano delle pessime scelte, tecniche e progettuali, soprattutto su un progetto del genere.

Andiamo con ordine, il block editor che troviamo in WordPress non è altro che il plugin Gutenberg, che ogni x versioni stabili riversano all'interno del core.

Sul progetto Gutenberg, non inteso per essere usato in produzione, vengono introdotte nuove soluzioni/funzionalità per essere testate e rifinite in vista di un aggiornamento di WordPress, che con l'avvento del Site editor e l'introduzione del theme.json file sono diventate sempre più profonde man mano che la complessità è aumentata (come è ragionevole aspettarsi).

Experimental solo di nome

Nel plugin di Gutenberg quando introducono una nuova funzionalità che deve essere verificata questa viene prefissata con __experimental, un modo anche per avvisare gli utenti (è più ad uso e consumo dei dev in realtà) che quella funzionalità potrebbe cambiare nel tempo o non è da considerarsi definitiva/stabile a sufficienza per poter essere usata in produzione, o quanto meno è quello che la parola "sperimentale" suggerisce.

Dietro questa flag ci sono chiaramente tante tipologie di supporti, tra cui __experimentalLayout collegato a tutta una serie di blocchi come colonne, gruppi, bottoni, ecc. che, semplificando, devono mostrare un contenuto più strutturato che richiede un display flex, gap e via dicendo.

Questo supporto viene dichiarato nei "supports" della definizione del blocco stesso, il block.json file di ogni singolo blocco di core e letto nella funzione wp_render_layout_support_flag che, insieme ad altre manipolazioni, è incaricata sostanzialmente di generare tramite wp_get_layout_style lo stile di "layout" per il blocco interessato.

Fin qui niente di strano se non fosse che il flag __experimental è stato portato nel core di WordPress ed applicato nei supports dei blocchi di core ed abilitato di default, cosa decisamente bizzarra per quanto mi riguarda e che magari avrei lasciato a discrezione degli utenti, come era stato fatto in passato per esempio proprio sul plugin di Gutenberg per testare il Site editor, mettendoli quindi in guardia che qualcosa poteva non funzionare nel tema da loro utilizzato.

Regressione stilistica

Legata in qualche modo a questo filtro c'è infine la seconda e più grave scelta progettuale che è quella di generare dello stile programmaticamente e associarlo al blocco tramite una nuova classe auto generata con un unique id.

In questo caso l'errore è grave per due motivi:

1. Sono state rimosse le classi di riferimento alla base per esempio degli allineamenti nel blocco buttons, un pattern universalmente riconosciuto e adottato sin dalle prime versioni andando così a rompere la compatibilità e creando inconsistenza nel progetto in quanto class is- o has- vengono ancora utilizzate
2. creare lo stile programmaticamente non ha alcun beneficio perché oltre a creare ridondanza rende la sovrascrittura del CSS più scomoda e si, va preso in considerazione che un utente possa voler alterare l'aspetto di un blocco di core. In questo modo ci si ritroverà con due classi aventi lo stesso livello di specificità 0,0,1,0 dove quella generata, essendo definita per ultima, vincerà su quella dichiarata nel foglio di stile.

Questa logica di layout può essere disabilitata con un semplice remove_filter('render_block', 'wp_render_layout_support_flag', 10, 2) ovviamente, ma se prima con un dequeue dello stile di core del Block editor mi ritrovavo con la logica di classi (quindi funzionalità backend legata al blocco di core) intatta ora mi ritrovo con, tornando all'esempio dei bottoni, un blocco con opzioni che non vengono trasmesse frontend forzandomi di fatto a ricrearle con filtro su render_block.

In rari casi lo stile generato può avere un senso, ma per come la vedo io dovrebbe essere vista come l'ultima spiaggia, perché facendolo si sta prendendo una posizione netta sul cosa può essere fatto lato foglio di stile, che è l'unico posto dove idealmente dovrebbe trovarsi tutta la logica CSS.

Questi casi, ovvero opzioni che generano un risultato stilistico di qualsiasi tipo, devono assolutamente essere gestite con criterio e consistenza su un progetto di questa portata ovvero con una metodologia, che sia BEM, Atomic CSS o quello che più ci sembra opportuno non ha importanza, l'importante è che sia applicato con coerenza, cosa che mi sembra sia un pò scappata di mano da qualche versione a questa parte.

Prima le fondamenta

Questa confusione e continua corsa ad aggiungere una nuova feature fiammante da pubblicizzare nel nuovo changelog sta facendo perdere di vista come dovrebbe essere gestito un progetto che ha una responsabilità del genere: le fondamenta.

Da quando è stato rilasciato il grande assente è sempre stato un sistema di gestione di media queries, che volenti o nolenti, ci ritroviamo sempre a dover gestire nel modo tradizionale, fintanto almeno che non prenderanno piede le container queries.

Di recente ho notato la proposta di aggiunta al supporto per la "Fluid typography" nel theme.json, approccio alla tipografia che mi sento di condividere in pieno in quanto più versatile, che potrebbe introdurre però, stante questa prima proposta, quello che è potenzialmente un problema.

"styles": {
    ....
    "typography": {
        "fluid": {
            "min": "768px",
            "max": "1600px"
        }, "fontSizes": [ {
                "size": "2rem",
                "fluidSize": {
                    "min": "2rem",
                    "max": "2.5rem"
                }, "slug": "medium", "name": "Medium" }, } } 

Quando si parla di tipografia fluida si parla tipicamente di un valore minimo e un valore (opzionale) massimo che tipicamente vengono associati a due soglie (o viewport size), in questo caso nella struttura di configurazione ritroviamo i primi due valori min e max di font size dentro un oggetto "fluidSize" all'interno dell'array di "fontSizes", fin qui niente di strano, se non fosse che le due soglie di viewport sono state inserite in un oggetto di nome "fluid" sempre all'interno di "typography".

Questa soluzione di per sé non è completamente sbagliata, il problema di semantica può essere corretto facilmente, ma la contestualizzazione sbagliata delle informazioni "fluid" (che non possono essere considerati proprietari della tipografia) porta a galla quello che è il problema più grosso, ovvero la gestione responsive dei blocchi, un problema strutturale che viene continuamente ignorato e che deve essere gestito assolutamente a livello di core.

Quello che vedo è qualcuno che cerca di costruire una casa pensando di poter inserire le fondamenta a lavoro ultimato.

Detto questo, per quanto mi riguarda il Block editor è ancora evidentemente un cantiere aperto anche per quelle che pensavo essere delle funzionalità base, pertanto su tutti quei progetti custom che devono essere mantenuti a lungo è bene attuare una strategia di prevenzione probabilmente.