Share
Il nuovo editor WordPress (nome in codice Gutenberg) è previsto per il rilascio nella versione 5.0. Ora è il momento perfetto per fare i conti con esso prima che arrivi al nucleo di WordPress. In questa serie, ti mostrerò come lavorare con l'API Block e creare blocchi di contenuto molto personali che puoi utilizzare per creare post e pagine.
Nel primo post di questa serie, abbiamo avuto una panoramica dell'API di blocco e creato un blocco semplice per il test. Daremo un'occhiata più da vicino alla Block API, ma prima modifichiamo il blocco predefinito che abbiamo creato nel post precedente per dare un'idea di quanto sia facile apportare modifiche a un blocco esistente.
Se ricordi, il nostro blocco personalizzato viene visualizzato in modo diverso sul fronte e sul retro per dimostrare che hai il controllo completo su come il blocco viene visualizzato all'interno dell'editor e su come i visitatori del sito vedono il blocco.
Se hai seguito e poi apri il / Wp-content / plugins / my-custom-block / src / blocco cartella in cui si trova il codice sorgente del blocco. Quella cartella contiene un file JavaScript e due file Sass, che controllano il comportamento del blocco e il modo in cui esegue il rendering all'interno dell'editor e sul front-end.
Il block.js Il file JavaScript contiene JSX, che viene transpiled 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 del plugin dist / cartella. Questi sono i file effettivi accodati da WordPress in quanto contengono JavaScript e CSS validi che tutti i browser possono comprendere.
Fortunatamente, il creare-Guten-block toolkit gestisce la costruzione e il transpiling per noi osservando le modifiche ai nostri file di blocco. Questa è davvero una bella caratteristica in quanto è una cosa in meno per noi di cui preoccuparsi. Possiamo semplicemente concentrarci sulla scrittura del nostro codice di blocco (e degli stili), ei file del plugin verranno automaticamente aggiornati. Bello!
Assicurati di eseguire il inizio di npm comando dalla cartella radice del plugin per attivare la sorveglianza del file.
Non preoccuparti dei dettagli del codice JSX in block.js appena come vedremo in dettaglio più avanti. Per ora, concentriamoci solo su alcune semplici modifiche all'output del blocco per le viste front e back end.
Aprire block.js, trovare la modificare metodo per l'oggetto che è il secondo argomento passato registerBlockType (), e sostituirlo con il seguente:
edit: function (props) return (); ,Vista Editor
Questo è il nostro blocco personalizzato all'interno dell'editor.
Aggiungiamo una lista non ordinata!
- Mela
- arancia
- Pera
- prugna
Questo metodo controlla il rendering del blocco nella finestra dell'editor. Ora trova il salvare metodo e sostituirlo con:
save: function (props) return (); ,Vista frontale
Questo è il nostro blocco personalizzato visto dai visitatori del sito.
Aggiungiamo una lista ordinata!
- Rosso
- Blu
- Rosa
- Marrone
Questo metodo viene utilizzato per rendere l'output del blocco sul front-end.
Nel style.scss, sostituire tutti gli stili con:
.wp-block-cgb-block-my-custom-block background: # a7d9f1; colore: #ffffff; border: 1px solid # 62afd4; border-radius: 15px; margine: 0 auto; larghezza massima: 740 px; imbottitura: 1.5rem; ol, ul margin-left: 20px! important; li margin-bottom: 0; h3 color: #ffffff; margin-top: 0;
Quindi, in editor.scss, sostituire tutti gli stili con:
.wp-block-cgb-block-my-custom-block background: # cba7f1; border: 1px solid # a170d6;
Puoi vedere negli screenshot qui sotto come queste modifiche influenzano il rendering del nostro blocco a seconda che lo stiamo visualizzando nella finestra dell'editor o nel front-end.
Non tratteremo ancora gli script di blocco di enqueueing, ma per ora è sufficiente saperlo editor.scss gli stili vengono applicati solo alla finestra dell'editor e style.scssè aggiunto a tutti e due la finestra dell'editor e il front-end. Pertanto, gli stili utilizzati sia nell'editor che nel front-end possono essere omessi style.scss.
Notate come nei file Sass facciamo riferimento a un lungo selettore CSS per indirizzare i nostri elementi di blocco.
.wp-block-CGB-block-my-custom-block
Questa classe viene automaticamente aggiunta da Gutenberg all'elemento contenitore del blocco sul front-end, ma dobbiamo applicarlo manualmente nella finestra dell'editor per ottenere la stessa classe, come si può vedere nel modificare metodo di seguito.
Il nome della classe generato da Gutenberg è determinato come segue: wp-block- [block namespace] - [nome del blocco.
Nel nostro caso, abbiamo usato il creare-Guten-block toolkit per creare il nostro blocco, che utilizza CGB per lo spazio dei nomi per impostazione predefinita e block-my-custom-block si basa sul nome del blocco che abbiamo specificato. Ciò si traduce nel nome della classe CSS wp-block-CGB-block-my-custom-block essere aggiunto al contenitore del blocco. Lo spazio dei nomi e il nome del blocco vengono utilizzati internamente da Gutenberg per identificare i blocchi in modo univoco.
Quando ho apportato modifiche ai file di blocco, ho trovato un paio di punti dolorosi degni di nota.
In primo luogo, quando si apportano modifiche al modificare metodo, mi sono trovato 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 è stato abbastanza spesso il caso. Se trovi la stessa cosa che ti succede, cancella la cache del browser e riprova.
In secondo luogo, quando si modifica il contenuto del salvare metodo, qualcosa di strano sembra accadere alla finestra dell'editor al prossimo aggiornamento.
Per dimostrarlo, ho aggiunto una nuova voce di elenco (salvare metodo e poi aggiornato l'editor di post (dopo aver cancellato di nuovo la cache, ovviamente!). Ecco il risultato:
Se si sceglie sia Converti in blocchi o Modifica come HTML quindi vieni presentato con i contenuti del salvare metodo, che deve essere visualizzato sul front-end e non nell'editor.
Questo è molto confuso e l'unico modo ovvio per riportare le cose alla normalità era eliminare il blocco dalla finestra dell'editor e reinserirlo di nuovo. Come ho già detto nel post precedente, Gutenberg è ancora in fase di lavorazione, e questo è un buon esempio di ciò!
Speriamo che questo sarà reso più intuitivo nelle versioni future, ma per ora è solo qualcosa a cui fare attenzione. Quando si apportano modifiche al salvare funzione, preparatevi a cancellare i blocchi correlati nella finestra dell'editor e aggiungerli di nuovo.
Come accennato in precedenza, l'output dal salvare e modificare i metodi possono essere completamente diversi. Tuttavia, nella maggior parte dei casi probabilmente vorrai che l'output front-end corrisponda all'output dell'editor in modo che l'esperienza di editing sia il più coerente possibile con il rendering front-end.
Nel nostro esempio inventato, ho aggiunto solo contenuti e stili diversi nell'editor e nella vista front-end a scopo dimostrativo.
L'API di blocco è costituita da un insieme di oggetti JavaScript aggiunti al globale wp oggetto admin. E perché wp è globale, non è necessario importarlo specificamente nel nostro codice sorgente, è disponibile su richiesta.
Gli oggetti disponibili in wp dipende dalla pagina di amministrazione che stai visualizzando. Ad esempio, se stai personalizzando il tuo sito allora wp include l'oggetto API principale di personalizzazione.
Al momento, tuttavia, l'API di Gutenberg Block è disponibile solo nell'editor dei post. Prevedo che questo cambierà in futuro quando l'integrazione tra l'editor di post e la personalizzazione del sito si avvicina.
È possibile visualizzare la struttura di wp aprendo l'editor Gutenberg ed entrando wp nella console del browser.
Come potete vedere, wp contiene molti oggetti, ma quelli che ci interessano di più sono:
Accentsconagua
wp.elementswp.blockswp.componentswp.datawp.i18nQuesti oggetti ti danno accesso a tutti gli strumenti necessari per creare blocchi molto complessi. Prova a digitare i nomi completi degli oggetti nella console del browser per esplorare ulteriormente questi oggetti.
Ad esempio, se digiti wp.blocks ed espandi l'oggetto, vedrai una delle funzioni disponibili registerBlockType (). Questa è una funzione molto importante che tratteremo in modo approfondito nel prossimo post
wp.elements OggettoQuesto oggetto è il livello di astrazione sopra React (e ReactDom) che espone la funzionalità React in modo prevedibile e coerente. Questo rimane vero anche se l'implementazione sottostante è alterata o cambiata completamente.
Fintanto che l'interfaccia rimane invariata, i plug-in che interagiscono con l'API Block non saranno interessati in futuro.
wp.blocks OggettoLa funzione principale per creare un blocco (registerBlockType ()) è contenuto in wp.blocks insieme ad altre funzioni necessarie per la gestione generale dei blocchi come:
getBlockType ()getBlockContent ()getBlockAttributes ()hasBlockSupport ()isValidBlock ()Questo oggetto contiene anche una serie di blocchi riutilizzabili che è possibile includere nei propri blocchi per fornire funzionalità senza sovraccarichi aggiuntivi. Questi blocchi pronti pronti all'uso possono accelerare notevolmente lo sviluppo dei blocchi, e ne utilizzeremo alcuni nel prossimo post mentre approfondiremo ulteriormente la creazione dei blocchi.
Alcuni di quelli disponibili sono:
wp.components OggettoIl wp.components oggetto contiene anche componenti riutilizzabili, ma questi sono più generici e vengono in genere utilizzati per creare ulteriori elementi dell'interfaccia utente nella finestra dell'editor, come i pannelli di controllo per le impostazioni dei blocchi.
Questi includono:
wp.data OggettoIl modulo dati gestisce lo stato dell'applicazione nell'editor Gutenberg, che include la memorizzazione delle impostazioni per ciascun blocco. Daremo un'occhiata a diversi modi in cui è possibile aggiungere le impostazioni a un blocco nel post finale di questa serie.
wp.data è implementato su Redux, quindi quando Gutenberg verrà unito al core, non avremo solo accesso a React ma anche a un archivio dati centralizzato completo basato su Redux!
Plugin e temi sono stati in grado di tradurre facilmente stringhe PHP per anni, e un metodo simile è anche disponibile per tradurre stringhe in JavaScript grazie al wp.i18n oggetto. Ciò significa che tutte le stringhe contenute nel blocco, inclusi il nome del blocco, le parole chiave e le etichette, possono essere tradotte in qualsiasi lingua.
Se hai già utilizzato le funzioni di traduzione PHP standard, ti sentirai a casa come il processo è praticamente lo stesso. Penso che questa sia una mossa intelligente in quanto incoraggerà gli sviluppatori a abilitare le traduzioni di stringhe nei loro blocchi fin dall'inizio.
All'interno del tuo codice di blocco, la traduzione di una stringa è semplice come:
wp.i18n .__ ('Questa stringa è traducibile', 'dominio-testo');In questo tutorial, abbiamo implementato un blocco di base e modificato il codice. Abbiamo anche visto che abbiamo il controllo totale sul rendering dei blocchi e possono avere viste di blocchi differenti nell'editor rispetto al front-end.
L'editore ha ancora alcuni problemi che possono sorprendervi di tanto in tanto - questo serve a ricordare che Gutenberg è ancora in fase di sviluppo e potrebbe non essere pronto per l'uso sui siti di produzione.
Infine, abbiamo terminato con una panoramica dell'API del blocco, che introduce diversi nuovi oggetti sul globale wp Oggetto JavaScript per creare e gestire i blocchi.
Nel prossimo post, prenderemo il ritmo e creeremo un blocco più completo. Per farlo, esploreremo il registerBlockType () funzione in profondità. Daremo inoltre un'occhiata più da vicino al corretto accodamento dei tuoi script di blocco.
