Share
Noul editor WordPress (codificat Gutenberg) se va lansa în versiunea 5.0. Acum este momentul perfect pentru a face față cu ea înainte de a ateriza în WordPress de bază. În această serie, vă voi arăta cum să lucrați cu API Block și să vă creați propriile blocuri de conținut pe care le puteți utiliza pentru a vă construi postările și paginile.
În primul post din această serie, am avut o prezentare generală a API-ului Block și am creat un bloc simplu pentru testare. Vom analiza mai repede API-ul Block, dar mai întâi să editați blocul implicit pe care l-am creat în postarea anterioară pentru a vă simți cât de ușor este să faceți modificări la un bloc existent.
Dacă vă aduceți aminte, blocul nostru personalizat a fost redat diferit pe capătul din față și din spate pentru a demonstra că aveți un control complet asupra modului în care blocul este redat în interiorul editorului și cum vizitatorii site-ului văd blocul.
Dacă ați urmărit apoi deschideți / Wp-content / plugins / mi-personalizat-bloc / src / bloc unde este localizat codul sursă al blocului. Acest dosar conține un fișier JavaScript și două fișiere Sass, care controlează comportamentul blocului și modul în care se redă în interiorul editorului și pe front.
block.js Fișierul JavaScript conține JSX, care este transpilat în timpul procesului de construire în JavaScript valid. În mod similar, cele două fișiere Sass sunt convertite la standardul CSS.
În timpul procesului de construire, aceste fișiere necesită prelucrare pentru a crea fișierele de distribuție din interiorul pluginului dist / pliant. Acestea sunt fișierele reale enumerate de WordPress, deoarece conțin JavaScript și CSS validate pe care toate browserele le pot înțelege.
Din fericire, crea-guten-bloc toolkit se ocupă de construirea și transpingerea pentru noi prin urmărirea modificărilor aduse fișierelor noastre bloc. Aceasta este o caracteristică foarte frumoasă, deoarece este un lucru mai puțin pentru noi să ne facem griji. Ne putem concentra doar pe scrierea codului nostru de bloc (și a stilurilor), iar fișierele plugin-ului se vor actualiza automat. Frumos!
Doar asigurați-vă că rulați npm start comanda din interiorul directorului root plugin pentru a declanșa vizionarea fișierelor.
Nu vă faceți griji cu privire la detaliile codului JSX din block.js tocmai pentru că vom acoperi în detaliu mai târziu. Pentru moment, să ne concentrăm doar pe efectuarea unor modificări simple la ieșirea blocurilor pentru vederile din față și din spate.
Deschide block.js, găsi Editați | × pentru obiectul care este cel de-al doilea argument registerBlockType (), și înlocuiți-l cu următoarele:
edita: funcția (recuzită) return (); ,Vizualizarea editorului
Acesta este blocul nostru personalizat din editor.
Să adăugăm o listă neordonată!
- măr
- portocale
- Pară
- Prună
Această metodă controlează modul în care blocul redă în fereastra editorului. Acum găsiți Salvați și înlocuiți-l cu:
salvați: funcția (recuzită) return (); ,Vizualizare Frontend
Acesta este blocul personalizat, așa cum văd vizitatorii site-ului.
Să adăugăm o listă ordonată!
- roșu
- Albastru
- Roz
- Maro
Această metodă este utilizată pentru a face ieșirea blocului la capătul din față.
În style.scss, înlocuiți toate stilurile cu:
.wp-block-cgb-bloc-meu-personalizat-bloc fundal: # a7d9f1; culoare: #ffffff; frontieră: 1px solid # 62afd4; raza de graniță: 15px; marja: 0 auto; max-lățime: 740px; padding: 1.5rem; ol, ul marginea-stânga: 20px! important; li margin-bottom: 0; h3 culoare: #ffffff; marginea superioară: 0;
Apoi în editor.scss, înlocuiți toate stilurile cu:
.wp-block-cgb-bloc-meu-personalizat-bloc fundal: # cba7f1; frontieră: 1px solid # a170d6;
Puteți vedea în capturile de ecran de mai jos modul în care aceste modificări afectează randarea blocului nostru în funcție de faptul că îl vedem în fereastra editorului sau în partea frontală.
Nu vom acoperi încă scripturile de blocare, dar este suficient ca acum să știm asta editor.scss stilurile se aplică doar ferestrei editorului și style.scssse adaugă la ambii fereastra editorului și capătul din față. Prin urmare, stilurile care sunt utilizate atât în editor cât și în partea frontală pot fi omise style.scss.
Observați cum în fișierele Sass menționăm un selector CSS de lungă durată pentru a viza elementele blocului nostru.
.wp-bloc-CGB-bloc-my-custom-bloc
Această clasă este adăugată în mod automat de Gutenberg la elementul container blocat pe front, dar trebuie să îl aplicăm manual în fereastra editorului pentru a obține aceeași clasă, după cum puteți vedea în Editați | × mai jos.
Numele de clasă generat de Gutenberg este determinat după cum urmează: wp-block- [namespace bloc] - [numele blocului.
În cazul nostru, am folosit crea-guten-bloc set de instrumente pentru a crea blocul nostru, care utilizează CGB pentru spațiul de nume în mod implicit și bloc-mea-custom-bloc se bazează pe numele blocului pe care l-am specificat. Acest lucru are ca rezultat numele clasei CSS wp-bloc-CGB-bloc-my-custom-bloc fiind adăugate la containerul de bloc. Spațiul de nume și numele blocului sunt utilizate de către Gutenberg pentru identificarea blocurilor în mod unic.
Când făceam modificări pentru blocarea fișierelor acolo, am găsit câteva puncte de durere care merită menționate.
În primul rând, atunci când efectuați modificări la Editați | × , am aflat că trebuie să șterg cache-ul browserului înainte de a reîmprospăta fereastra editorului pentru a vedea cele mai recente modificări. Acest lucru nu sa întâmplat tot timpul, dar a fost destul de des cazul. Dacă găsiți același lucru care se întâmplă cu dvs., trebuie doar să goliți memoria cache a browserului și să încercați din nou.
În al doilea rând, la editarea conținutului Salvați metodă, ceva ciudat pare să se întâmple la fereastra editorului atunci când este ulterior reîmprospătată.
Pentru a demonstra acest lucru, am adăugat un nou element de listă (Salvați și apoi reîmprospăta editorul post (după ce trebuie să golești din nou cache-ul, bineînțeles!). Iată rezultatul:
Dacă alegeți una dintre ele Conversia în blocuri sau Editați ca HTML atunci veți primi prezentarea conținutului Salvați care este concepută pentru a fi văzută pe front și nu în editor.
Acest lucru este foarte confuz și singura modalitate evidentă de a aduce lucrurile înapoi la normal a fost să ștergeți blocul din fereastra editorului și să îl reintroduceți din nou. După cum am menționat în postul anterior, Gutenberg este încă o lucrare în desfășurare, și acesta este un bun exemplu în acest sens!
Sperăm că acest lucru va deveni mai intuitiv în versiunile viitoare, dar deocamdată este doar un lucru de urmărit. Când faceți modificări la Salvați funcția, fiți pregătiți să ștergeți blocurile aferente din fereastra editorului și să le adăugați din nou.
Așa cum am menționat anterior, rezultatul din Salvați și Editați | × metodele pot fi complet diferite. Cu toate acestea, în majoritatea cazurilor, probabil că veți dori ca ieșirea de pe front să se potrivească cu ieșirea editorului, astfel încât experiența de editare să fie cât mai consistentă cu redarea din față.
În exemplul nostru prezentat mai sus, am adăugat conținut și stiluri diferite în editor și în vizualizarea front-end pentru demonstrații.
API-ul Block este alcătuit dintr-un set de obiecte JavaScript adăugate globale wp obiect de administrare. Și pentru că wp este global, nu avem nevoie să îl importăm în codul sursă - este disponibil la cerere.
Obiectele disponibile în wp depinde de pagina de administrare pe care o vizualizați în prezent. De exemplu, dacă personalizați site-ul dvs. atunci wp include obiectul customizator API.
În prezent, însă, API-ul Gutenberg Block este disponibil numai în editorul post. Anticipăm că acest lucru se va schimba în viitor, când integrarea între editorul postului și personalizatorul site-ului se va apropia.
Puteți vizualiza structura wp prin deschiderea editorului Gutenberg și intrarea wp în consola browserului.
După cum puteți vedea, wp conține multe obiecte, dar cele mai interesate sunt:
Accentsconagua
wp.elementswp.blockswp.componentswp.datawp.i18nAceste obiecte vă oferă acces la toate instrumentele necesare pentru crearea unor blocuri foarte complexe. Încercați să tastați numele lor complet de obiecte în consola browserului pentru a explora mai departe aceste obiecte.
De exemplu, dacă tastați wp.blocks și pentru a extinde obiectul, veți vedea una dintre funcțiile disponibile este registerBlockType (). Aceasta este o funcție foarte importantă pe care o vom acoperi în profunzime în următorul post
wp.elements ObiectAcest obiect este stratul de abstractizare deasupra React (și ReactDom) care expune funcționalitatea React într-un mod previzibil și consecvent. Acest lucru rămâne valabil chiar dacă implementarea subiacentă este modificată sau complet modificată.
Atâta timp cât interfața rămâne aceeași, pluginurile care interacționează cu API-ul Block nu vor fi afectate în viitor.
wp.blocks ObiectFuncția de bază pentru a crea un bloc (registerBlockType ()) este conținut în wp.blocks împreună cu alte funcții necesare pentru gestionarea blocului general, cum ar fi:
getBlockType ()getBlockContent ()getBlockAttributes ()hasBlockSupport ()isValidBlock ()Acest obiect conține, de asemenea, un set de blocuri reutilizabile pe care le puteți include în blocurile proprii pentru a vă oferi funcționalități fără cheltuieli suplimentare. Aceste blocuri pregătite în afara blocului pot accelera dramatic dezvoltarea blocului și vom folosi unele dintre ele în următoarea postare pe măsură ce vom continua să realizăm blocarea.
Unele dintre cele disponibile sunt:
wp.components Obiect wp.components obiectul conține, de asemenea, componente reutilizabile, dar acestea sunt mai generice și sunt utilizate în mod obișnuit pentru a crea elemente UI suplimentare în fereastra editorului, cum ar fi panourile de control pentru setările de bloc.
Acestea includ:
wp.data ObiectModulul de date gestionează starea aplicației în editorul Gutenberg, care include stocarea setărilor pentru fiecare bloc. Vom analiza diferite modalități în care puteți adăuga setări la un bloc în postarea finală a acestei serii.
wp.data este implementat pe Redux, deci atunci când Gutenberg este fuzionat cu nucleul, nu vom avea doar acces la React, ci și la un magazin complet de date centralizat, alimentat de Redux!
Pluginurile și temele au fost capabile să traducă cu ușurință șiruri PHP de ani de zile și o metodă similară este disponibilă și pentru traducerea șirurilor în JavaScript grație wp.i18n obiect. Aceasta înseamnă că toate șirurile conținute în blocul dvs. - inclusiv numele blocului, cuvintele cheie și etichetele - pot fi traduse în orice limbă.
Dacă ați folosit funcțiile standard de traducere PHP înainte de acel moment, vă veți simți ca acasă deoarece procesul este aproape același. Cred că este o mișcare inteligentă, deoarece va încuraja dezvoltatorii să permită traducerile de șir din blocurile lor de la început.
În interiorul codului blocului, traducerea unui șir este la fel de simplă:
wp.i18n .__ ('Acest șir este translatabil', 'text-domain');În acest tutorial, am implementat un bloc de bază și am editat codul. De asemenea, am văzut că avem un control total asupra randării în bloc și că putem avea diferite vederi de bloc în editor în comparație cu partea frontală.
Editorul are în continuare câteva probleme care pot să vă ia prin surprindere din când în când - acest lucru servește ca un memento că Gutenberg este încă în curs de dezvoltare și poate să nu fie gata de utilizare pe site-urile de producție.
În cele din urmă, am terminat cu o prezentare generală a blocului API, care introduce câteva obiecte noi pe glob wp Obiect JavaScript pentru a crea și administra blocuri.
În următorul post, vom ridica ritmul și vom crea un bloc mai cuprinzător. Pentru a face acest lucru, vom explora registerBlockType () funcționează în profunzime. De asemenea, vom analiza mai îndeaproape modul în care încorporați scripturile bloc.
