Come sfruttare al meglio Gutenberg su un tema custom

Nell'ultimo anno in Evolve abbiamo avuto modo di lavorare a grossi progetti WordPress sui quali abbiamo sperimentato approcci diversi per gestire il Block editor e visto che al termine di ogni progetto facciamo sempre un'analisi interna di cosa ha funzionato e cosa no, vorrei condividere 3 consigli per tutti coloro che intendono cimentarsi nello sviluppo di progetti custom e vogliono sfruttare al meglio il Block editor.

1 - Disabilitare il foglio di stile del Block editor

Stiamo parlando di sviluppare un tema custom giusto? Bene, la prima cosa da fare allora, ma forse non la più ovvia, è quella di rimuovere lo stile di default del Block editor:

add_action( 'wp_enqueue_scripts', function() {
  wp_dequeue_style( 'wp-block-library' );
}); 

Questo perché dovrete seguire una style guide ed un design che non necessariamente condivideranno delle scelte presenti nel foglio di stile di default, e anche se è vero che potete sempre sovrascrivere una regola, consiglio sempre di non farlo (come già affrontato per il reset) a meno che non ci siano altre soluzioni possibili.

Altro punto a favore della rimozione è che nel foglio di stile di default sono presenti stili per tutti i blocchi del Block editor, ma non è detto che siano tutti necessari nel nostro progetto.

2 - Ridefinire le regole di colore

Il Block editor ci mette a disposizione tre theme supports per gestire la style guide del nostro progetto, editor-font-sizes, editor-color-palette e editor-gradient-presets, i quali generano un set di classi che ci permettono di capire quale font size, colore o gradiente è stato applicato.

Per quanto riguarda i colori le classi generate sono sostanzialmente 2, una che specifica quale colore è stato scelto più una che ci comunica che è stato scelto un colore per il testo o per lo sfondo.

Quest'ultima classe francamente trovo che sia un pò ridondante, perché con un selettore [class*=] potremmo senza grossi problemi riuscire ad identificare entrambi i casi, mentre per quanto riguarda la classe che identifica il colore la sintassi è: has-{colore}-{background/text}-color.

Tipicamente l'implementazione che viene fatta di queste classi è:

.has-red-background-color {
  background-color: red;
} .has-red-text-color {
  color: red;
} 

Fin qui diciamo che è tutto standard, quello che invece trovo particolarmente utile fare è salvarmi anche una variabile CSS con il codice del colore in questo modo:

.has-red-background-color {
  --background-color: red;
  background-color: var(--background-color);
} .has-red-text-color {
  --color: red;
  color: var(--color);
} 

Probabilmente vi starete chiedendo; cosa me ne faccio di una variabile se ho già la regola standard?

Facciamo un esempio, ipotizziamo di utilizzare il colore di sfondo su una colonna, ma non vogliamo che il colore di sfondo venga applicato direttamente alla colonna ma un pseudo elemento, per poterlo spostare diciamo fuori asse orizzontalmente rispetto alla colonna.

Avendo a disposizione la variabile possiamo permetterci di applicare un background-color: transparent alla nostra colonna e leggere nel nostro :before il background-color gestito dalla palette del progetto.

Generare le classi dei colori con Sass è estremamente semplice (ipotizzando di avere una mappa con l'elenco dei nostri colori):

@each $name, $color in map-get( $colors ) {
  .has-#{$name}-color {
    --color: var(--color-#{$name}); color: var(--color); }; .has-#{$name}-background-color {
    --background-color: var(--color-#{$name}); background-color: var(--background-color); }; } 

Le variabili chiaramente dovranno essere salvate a parte e associate a :root, similmente come per le classi possiamo iterare sulla stessa mappa di configurazione:

:root {
  @each $name, $color in map-get( $colors ) {
    --color-#{$name}: #{$color}; } } 

3 - Sfruttare al massimo il blocco gruppo

Gli stili sui blocchi sono estremamente utili e in particolare quando si associano al blocco probabilmente più sottovalutato di tutti, ovvero il blocco "gruppo".

Questo blocco è incredibilmente utile perché ci permette di mettere insieme più blocchi e racchiuderli in un <div> che nella maggior parte dei casi è tutto quello che ci serve per poter applicare poi il nostro stile custom ed evitare così di creare un blocco custom con Advanced Custom Fields.

Uno stile custom si dichiara utilizzando register_block_style in questo modo:

add_action('init', function() {
  register_block_style('core/group', [
    'name' => 'nome-dello-stile',
    'label' => __('Nome dello stile', 'textdomain'),
  ]);
}); 

La visualizzazione dello stile nella sidebar non era il massimo, soprattutto su blocchi particolari come i gruppi ma fortunatamente lo stile è stato rivisto in una delle ultime versioni di Gutenberg (e speriamo di vederlo presto anche nel Block editor), rendendolo di fatto più simile ad un bottone e di riflesso più gestibile in progetti dove si definiscono molti stili custom.

Bonus

Non sempre è possibile modificare un blocco usando solamente il foglio di stile, per esempio se necessitiamo di aggiungere un'icona svg al blocco button in modo da poterne manipolare successivamente lo stile via CSS.

Fortunatamente WordPress ci mette a disposizione un filtro chiamato render_block che è un pò l'ultima spiaggia per poter manipolare i dati del nostro blocco prima che questo venga renderizzato.

Con questo filtro possiamo leggere le informazioni del blocco contenute in $block ed effettuare manipolazioni su $block_content che di fatto è il markup del nostro blocco.

Tornando al nostro esempio, volendo aggiungere un'icona svg al nostro bottone un metodo veloce che possiamo usare è quello di manipolare il markup con uno string replace:

add_filter(
  'render_block',
  function( $block_content, $block ) {
    if( "core/button" !== $block['blockName'] ) {
		  return $block_content;
		} return str_replace( "</a>", "<svg>…</svg></a>", $block_content );
  } 10,3 ); 

Questo metodo magari non è proprio intuitivo e richiede anche una buona dose di attenzione ma al momento è anche l'unico che abbiamo a disposizione per modificare il markup di un blocco (non creato da noi chiaramente) prima che questo venga renderizzato.