Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. WordPress
Code

Block API di WordPress Gutenberg: lo stile del blocco

by
Difficulty:IntermediateLength:MediumLanguages:
This post is part of a series called WordPress Gutenberg Block API.
WordPress Gutenberg Block API: An Introduction
WordPress Gutenberg Block API: Creating Custom Blocks

Italian (Italiano) translation by Cinzia Sgariglia (you can also view the original English article)

Il nuovo editor di WordPress (nome in codice Gutenberg) sarà rilasciato nella versione 5.0. Ora è il momento perfetto per prendere confidenza con esso prima che finisca nel core di WordPress. In questa serie, vi mostrerò come lavorare con le Block API e creare i vostri blocchi di contenuto che potete utilizzare per costruire il vostro post e le pagine.

Nel primo articolo di questa serie, abbiamo avuto una panoramica del Block API e creato un semplice blocco da testare. Daremo uno sguardo più attento al Block API brevemente, ma prima modifichiamo il blocco predefinito che abbiamo creato nel precedente articolo per avere un'idea di quanto sia facile apportare delle modifiche a un blocco esistente.

Se ricordate, il nostro blocco personalizzato eseguiva il rendering in modo diverso sul front-end e il back-end per dimostrare che avete il controllo completo sulla modalità di rendering del blocco all'interno dell'editor e di come i visitatori del sito vedono il blocco.

Default views for our custom block

Se avete seguito il tutto allora aprite la cartella /wp-content/plugins/my-custom-block/src/block dove si trova il codice sorgente del blocco. Tale cartella contiene un file JavaScript e due file Sass, che controllano il comportamento del blocco e come viene eseguito il rendering all'interno dell'editor e sul front-end.

Block source code files

Il file JavaScript block.js contiene JSX, che viene tradotto durante il processo di compilazione in JavaScript valido. Allo stesso modo, i due file Sass vengono convertiti in CSS standard.

Durante il processo di compilazione, questi file richiedono l'elaborazione per creare i file di distribuzione all'interno della cartella del plugin dist/. Questi sono i file effettivi che vengono accodati da WordPress in quanto contengono JavaScript e CSS validi che possono comprendere tutti i browser.

Fortunatamente, il toolkit di create-guten-block gestisce la costruzione e traduzione per noi guardando le modifiche ai nostri file del blocco. Si tratta di una funzione veramente bella poiché è una cosa in meno di cui preoccuparsi. Possiamo concentrarci su come scrivere il nostro codice del blocco (e gli stili), e i file del plugin verranno aggiornati automaticamente. Ottimo!

Assicuratevi solo di eseguire il comando di npm start all'interno della cartella radice del plugin per attivare il controllo del file.

È ora di modificare il codice!

Non preoccupatevi per i dettagli del codice JSX in block.js per ora poiché li vedremo in dettaglio più avanti. Per ora, concentriamoci su come effettuare alcune semplici modifiche al blocco di output per il front-end e il back-end.

Aprite block.js, trovate il metodo edit per l'oggetto che è il secondo argomento passato a registerBlockType() e sostituitelo con il seguente:

Questo metodo controlla come il blocco esegue il rendering nella finestra dell'editor. Ora trovate il metodo save e sostituitelo con:

Questo metodo è utilizzato per il rendering dell'output di blocco sul front-end.

In style.scss, sostituite tutti gli stili con:

Quindi, in editor.scss, sostituite tutti gli stili con:

Potete vedere negli screenshot qui sotto come questi cambiamenti influenzano il rendering del nostro blocco a seconda se lo stiamo visualizzando nella finestra dell'editor o del front-end.

Updated editor view
Updated frontend view

Non copriremo gli script del blocco in coda per ora, ma è abbastanza per ora sapere che gli stili di editor.scss vengono applicati solo per l'editor della finestra e style.scss è aggiunto sia alla finestra dell'editor sia al front-end. Di conseguenza, gli stili sono utilizzati sia nell'editor che sul front-end possono essere omessi da style.scss.

Notate come nei file Sass ci riferiamo a un selettore CSS lungo per indirizzare i nostri elementi di blocco.

Questa classe viene automaticamente aggiunta da Gutenberg all'elemento del contenitore del blocco sul front-end, ma dobbiamo applicarla manualmente nella finestra dell'editor per ottenere la stessa classe, come si può vedere nel metodo edit qui sotto.

Il nome della classe generato da Gutenberg è determinato come segue: wp-block-[block namespace]-[block name].

Nel nostro caso, abbiamo usato il toolkit create-guten-block per creare il nostro blocco, che, per impostazione predefinita, utilizza cgb per il namespace, e block-my-custom-block è basato sul nome del blocco che abbiamo specificato. Risulta il nome della classe CSS wp-block-cgb-block-my-custom-block essendo aggiunto al contenitore del blocco. Il namespace e il nome del blocco sono utilizzati internamente da Gutenberg per identificare in modo univoco i blocchi.

Quando apportavo delle modifiche ai file dl blocco, ho trovato un paio di punti dolorosi degni di nota.

In primo luogo, quando apportavo modifiche al metodo edit, mi ritrovai a dover cancellare la cache del browser prima di aggiornare la finestra dell'editor per vedere le ultime modifiche. Questo non è accaduto tutto il tempo, ma accadeva abbastanza spesso. Se vi ritrovate che vi accade la stessa cosa, basta cancellare la cache del browser e riprovare.

In secondo luogo, quando modificavo il contenuto del metodo save, qualcosa di strano sembra accadere alla finestra dell'editor quando viene successivamente aggiornato.

Per dimostrarlo, ho aggiunto una nuova lista di elementi (<li>Indigo</li>) nel metodo save e poi ho  aggiornato l'editor del post (dopo aver per cancellato di nuovo la cache, naturalmente!). Ecco il risultato:

Block update issue

Se scegliete Converti in blocchi o Modifica come HTML quindi si presenta con il contenuto del metodo save, che doveva essere visualizzato sul front-end e non nell'editor.

Convert to blocks and edit as HTML views

Questo è molto confuso, e il solo modo ovvio per portare le cose alla normalità è stato quello di eliminare il blocco dalla finestra dell'editor e reinserirlo nuovamente. Come ho detto nel post precedente, Gutenberg è ancora un work in progress, e questo è un buon esempio di ciò!

Speriamo che ciò sarà reso più intuitivo nelle versioni future, ma per ora è solo una cosa a cui stare attenti. Quando apportate modifiche alla funzione save, preparatevi a eliminare i blocchi correlati nella finestra dell'editor e ad aggiungerli nuovamente.

Come accennato in precedenza, l'output dai metodi save ed edit possono essere completamente diversi. Tuttavia, nella maggior parte dei casi probabilmente si vorrà che l'output del front-end si abbini all'output dell'editor in modo che l'esperienza di editing sia il più coerente possibile con il rendering del front-end.

Nel nostro esempio artificioso sopra, ho aggiunto solo contenuti e stili diversi nell'editor e nella vista del front-end per scopi dimostrativi.

Panoramica sul Block API

Il Block API è costituito da un insieme di oggetti JavaScript aggiunto all'oggetto globale di admin wp. E poiché wp è globale, non abbiamo bisogno di importarlo in particolare nel nostro codice sorgente — è disponibile su richiesta.

Gli oggetti disponibili in wp dipendono dalla pagina admin che state visualizzando. Per esempio, se si sta personalizzando il vostro sito wp include l'oggetto principale personalizzato dell'API.

Attualmente, tuttavia, il Block API di Gutenberg è disponibile solo sull'editor dei post. Prevedo che questo cambierà in futuro quando si avvicinerà l'integrazione tra l'editor dei post e il customizer del sito.

È possibile visualizzare la struttura di wp aprendo l'editor di Gutenberg e immettendo wp nella console del browser.

Block API objects added to global wp JavaScript object

Come potete vedere, wp contiene molti oggetti, ma quelli a cui siamo più interessati sono:

Questi oggetti consentono di accedere a tutti gli strumenti necessari per creare alcuni blocchi molto complessi. Provate a digitare i nomi dell'oggetto completo nella console del browser per esplorare ulteriormente questi oggetti.

Ad esempio, se digitate in wp.blocks ed espandete l'oggetto, vedrete che una delle funzioni disponibili è registerBlockType(). Si tratta di una funzione molto importante, che verrà trattata in modo approfondito nel prossimo post

L'oggetto wp.elements

Questo oggetto è il livello di astrazione superiore di React (e ReactDom) che espone la funzionalità di React in modo coerente e prevedibile. Ciò resta vero anche se l'implementazione sottostante è alterata o è completamente cambiata.

Fintanto che l'interfaccia rimane la stessa, i plugin che interagiscono con il Block API non saranno interessati in futuro.

L'oggetto wp.blocks

La funzione principale per creare un blocco (registerBlockType()) è contenuta in wp.blocks insieme ad altre funzioni necessarie per la gestione generale dei blocchi come:

  • getBlockType()
  • getBlockContent()
  • getBlockAttributes()
  • hasBlockSupport()
  • isValidBlock()

Questo oggetto contiene inoltre un insieme di blocchi riutilizzabili che è possibile includere nei vostri blocchi per offrire funzionalità senza le spese generali supplementari. Questi blocchi pronti all'uso possono accelerare lo sviluppo del blocco drasticamente, e ne farete uso di alcuni di loro nel prossimo post come approfondiremo ulteriormente nella creazione del blocco.

Alcuni di quelli disponibili sono:

  • barra degli strumenti di allineamento
  • completamento automatico
  • uploader dei media
  • tavolozza dei colori
  • editor di testo arricchito

L'oggetto wp.components

L'oggetto wp.components contiene anche componenti riutilizzabili, ma questi sono più generici e in genere vengono utilizzati per creare elementi di interfaccia utente aggiuntivi nella finestra dell'editor, quali i pannelli di controllo per le impostazioni del blocco.

Questi includono:

  • pulsante
  • casella di controllo
  • editor di codice
  • Icone dash
  • data/ora
  • menu a discesa
  • voce di menu
  • pulsante di opzione
  • intervallo di controllo

L'oggetto wp.data

Il modulo dati gestisce lo stato dell'applicazione nell'editor di Gutenberg, che comprende la memorizzazione delle impostazioni per ogni blocco. Daremo un'occhiata a diversi modi con cui potete aggiungere le impostazioni a un blocco nel post finale di questa serie.

wp.data è implementato su Redux, così quando Gutenberg è fusa con il core, non avremo solo accesso a React, ma anche a un archivio di dati centralizzato completo alimentato da Redux!

L'oggetto wp.i18n

I plugin e i temi sono stati in grado di tradurre facilmente le stringhe PHP ormai da anni, e un metodo simile è anche disponibile per la conversione delle stringhe in JavaScript grazie all'oggetto wp.i18n. Questo significa che tutte le stringhe contenute nel blocco — tra cui il nome del blocco, parole chiavi ed etichette — può essere tradotto in qualsiasi lingua.

Se avete utilizzato le funzioni di traduzione standard di PHP prima allora vi sentirete proprio come a casa poiché il processo è praticamente lo stesso. Penso che si tratta di una mossa intelligente poiché incoraggerà gli sviluppatori a consentire le traduzioni della stringa nei loro blocchi fin dall'inizio.

All'interno del codice di blocco, tradurre una stringa è semplice come:

Conclusione

In questo tutorial, abbiamo implementato un blocco base e modificato il codice. Abbiamo anche visto che abbiamo un controllo totale sul rendering del blocco e possiamo avere visualizzazioni diverse del blocco nell'editor rispetto al front-end.

L'editor ha ancora alcuni problemi che possono cogliere di sorpresa di volta in volta — questo serve come un promemoria che Gutenberg è ancora in sviluppo e potrebbe non essere pronto per l'uso su siti di produzione.

Infine, abbiamo finito con una panoramica del Block API, che introduce diversi nuovi oggetti sull'oggetto JavaScript wp globale per creare e gestire i blocchi.

Nel prossimo post, terremo il passo e creeremo un blocco più completo. A tale scopo, esploreremo la funzione registerBlockType() in profondità. Daremo anche un'occhiata più da vicino il prodotto correttamente gli script di blocco.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.