Priznajmo, da je trenutno razvijanje za WordPress čudno. Ne glede na to, ali ste novi v WordPressu ali ste z njim delali že več let, uvedba funkcij »Full-Site Editing« (FSE), vključno z Urejevalnik blokov (WordPress 5.0) in Urednik spletnega mesta (WordPress 5.9), so spremenili tradicionalni način izdelave tem in vtičnikov WordPress.
Čeprav je minilo pet let, odkar smo se prvič srečali z urejevalnikom blokov, je razvoj zanj težaven, ker dokumentacija manjka ali je zastarela. To je bolj izjava o tem, kako hitro se premikajo funkcije FSE Geoff je obžaloval v nedavni objavi.
Primer: Leta 2018 je an uvodna serija o vstopu v Gutenbergov razvoj je bil objavljen tukaj na CSS-tricks. Časi so se od takrat spremenili in, čeprav ta slog razvoja še vedno deluje, je ni priporočljivo več (poleg tega create-guten-block projekt, na katerem temelji, prav tako ni več vzdrževan).
V tem članku vam nameravam pomagati začeti z razvojem blokov WordPress na način, ki sledi trenutni metodologiji. Torej, da, po objavi tega se lahko stvari zelo spremenijo. Vendar se bom poskušal osredotočiti na to na način, ki upam, da bo zajel bistvo razvoja blokov, kajti čeprav se bodo orodja sčasoma razvijala, bodo glavne ideje verjetno ostale enake.
Začnimo tako, da odpravimo nekaj zmede glede tega, kaj mislimo z izrazi, kot je bloki. Ves razvoj teh funkcij, ki je vodil do WordPressa 5.0, je imel kodno ime »Gutenberg” — saj veste, izumitelj tiskarski stroji.
Od takrat se »Gutenberg« uporablja za opis vsega, kar je povezano z bloki, vključno z urejevalnikom blokov in urejevalnikom spletnih mest, zato je postalo zapleteno do te mere, da nekateri zaničevati ime. Za piko na i pa še Gutenbergov vtičnik kjer so eksperimentalne funkcije testirane za morebitno vključitev. In če mislite, da bi vse to poimenovali »urejanje celotnega mesta«, bi rešili težavo, tudi glede tega so pomisleki.
Torej, ko v tem članku govorimo o »blokih«, mislimo na komponente za ustvarjanje vsebine v urejevalniku blokov WordPress. Bloki so vstavljeni na stran ali objavo in zagotavljajo strukturo za določeno vrsto vsebine. WordPress je opremljen s peščico "jedrnih" blokov za običajne vrste vsebine, kot so odstavek, seznam, slika, video in zvok, našteti jih nekaj, imenovati jih nekaj.
Poleg teh osnovnih blokov lahko ustvarimo tudi bloke po meri. To je bistvo razvoja blokov WordPress (obstaja tudi filtriranje jedrnih blokov za spreminjanje njihove funkcionalnosti, vendar tega verjetno še ne boste potrebovali).
Kaj počnejo bloki
Preden se poglobimo v ustvarjanje blokov, moramo najprej dobiti občutek, kako bloki delujejo interno. To nam bo kasneje zagotovo prihranilo kup frustracij.
Način, kako rad razmišljam o bloku, je precej abstrakten: zame je blok entiteta z nekaterimi lastnostmi (imenovanimi atributi), ki predstavlja neko vsebino. Vem, da to zveni precej nejasno, ampak ostani pri meni. Blok se v osnovi manifestira na dva načina: kot grafični vmesnik v urejevalniku blokov ali kot kos podatkov v bazi podatkov.
Ko odprete WordPress Block Editor in vstavite blok, recimo blok Pullquote, dobite prijeten vmesnik. Lahko kliknete ta vmesnik in uredite citirano besedilo. Plošča z nastavitvami na desni strani uporabniškega vmesnika urejevalnika blokov ponuja možnosti za prilagoditev besedila in nastavitev videza bloka.
Ko končate z ustvarjanjem svojega modnega citata in pritisnete Objavi, se celotna objava shrani v zbirko podatkov v wp_posts tabela. Zaradi Gutenberga to ni nič novega. Tako so stvari vedno delovale – WordPress shranjuje vsebino objave v določeni tabeli v bazi podatkov. Toda novost je to predstavitev bloka Pullquote je del vsebine, ki je shranjena v post_content polje polja wp_posts miza.
Kako izgleda ta predstavitev? Poglej:
It is not an exaggeration to say that peas can be described as nothing less than perfect spheres of joy.
The Encyclopedia of world peas
Izgleda kot navaden HTML, kajne?! V tehničnem jeziku je to "serializiran" blok. Bodite pozorni na podatke JSON v komentarju HTML, "textAlign": "right". To je atribut — lastnost, povezana z blokom.
Recimo, da zaprete urejevalnik blokov in ga čez nekaj časa znova odprete. Vsebina iz ustreznega post_content polje pridobi urejevalnik blokov. Urejevalnik nato razčleni pridobljeno vsebino in povsod, kjer naleti na to:
...
... si reče naglas:
OK, to se mi zdi kot Pullquote blok. Hmm.. ima tudi atribut ... Imam datoteko JavaScript, ki mi pove, kako iz njegovih atributov sestaviti grafični vmesnik za blok Pullquote v urejevalniku. To bi moral storiti zdaj, da bi ta blok prikazal v vsem svojem sijaju.
Kot razvijalec blokov je vaša naloga:
Povejte WordPressu, da želite registrirati določeno vrsto bloka, s temi in temi podrobnostmi.
Urejevalniku blokov posredujte datoteko JavaScript, ki mu bo pomagala pri upodabljanju bloka v urejevalniku, hkrati pa jo bo "serializirala", da jo bo shranila v bazo podatkov.
Zagotovite vse dodatne vire, ki jih blok potrebuje za pravilno delovanje, npr. sloge in pisave.
Upoštevati je treba, da vsa ta pretvorba iz serializiranih podatkov v grafični vmesnik - in obratno - poteka samo v urejevalniku blokov. Na sprednji strani je vsebina prikazana točno tako, kot je shranjena. Zato so bloki v nekem smislu domiseln način vnosa podatkov v bazo podatkov.
Upajmo, da vam bo to dalo nekaj jasnosti glede delovanja bloka.
Kako začeti z razvojem blokov WordPress
Bloki so samo vtičniki
Bloki so samo vtičniki. No, tehnično, ti lahko postavite bloke v teme in vi lahko postavite več blokov v vtičnik. Vendar pogosteje kot ne, če želite narediti blok, boste naredili vtičnik. Torej, če ste kdaj ustvarili vtičnik za WordPress, ste že delno pripravljeni na izdelavo bloka WordPress.
Toda za trenutek predpostavimo, da še nikoli niste nastavili vtičnika WordPress, kaj šele bloka. Kje sploh začneš?
Postavitev bloka
Pokrili smo, kaj so bloki. Začnimo pripravljati stvari, da ga naredimo.
Preverite, ali imate nameščen Node
To vam bo omogočilo dostop do npm in npx ukazi, kje npm namesti odvisnosti vašega bloka in pomaga pri prevajanju stvari, medtem ko npx izvaja ukaze na paketih, ne da bi jih namestil. Če uporabljate macOS, verjetno že imate Node in ga lahko uporabljate nvm za posodobitev različic. Če uporabljate Windows, boste morali prenesite in namestite Node.
Ustvarite mapo projekta
Zdaj lahko naletite na druge vadnice, ki skočijo naravnost v ukazno vrstico in vam naročijo, da namestite paket, imenovan @wordpress/create-block. Ta paket je odličen, ker prikaže popolnoma oblikovano projektno mapo z vsemi odvisnostmi in orodji, ki jih potrebujete za začetek razvoja.
Osebno grem po tej poti, ko postavljam lastne bloke, vendar mi je za trenutek v veselje, ker želim poseči po samozavestnih stvareh, ki jih uvaja, in se osredotočiti samo na zahtevane dele zaradi razumevanja osnovnega razvojnega okolja.
To so datoteke, ki bi jih rad posebej izpostavil:
readme.txt: To je nekakšna sprednja stran imenika vtičnikov, ki se običajno uporablja za opis vtičnika in ponuja dodatne podrobnosti o uporabi in namestitvi. Če svoj blok oddate na WordPress Plugin Directory, ta datoteka pomaga zapolniti stran vtičnika. Če nameravate ustvariti repo GitHub za svoj blokovni vtičnik, lahko razmislite tudi o README.md datoteko z enakimi informacijami, tako da je tam lepo prikazana.
package.json: To definira pakete Node, ki so potrebni za razvoj. Odprli ga bomo, ko bomo prišli do namestitve. Pri klasičnem razvoju vtičnikov WordPress ste morda navajeni delati s Composerjem in a composer.json datoteko namesto tega. To je enakovredno temu.
plugin.php: To je glavna datoteka vtičnika in ja, to je klasični PHP! Tukaj bomo vstavili glavo vtičnika in metapodatke ter jih uporabili za registracijo vtičnika.
Poleg teh datotek obstaja tudi src imenik, ki naj bi vseboval izvorno kodo našega bloka.
Ob teh datotekah in src Imenik je vse, kar potrebujete za začetek. Iz te skupine, upoštevajte to tehnično potrebujemo samo eno datoteko (plugin.php), da ustvarite vtičnik. Ostali bodisi zagotavljajo informacije bodisi se uporabljajo za upravljanje razvojnega okolja.
Navedeno @wordpress/create-block Package gradi te datoteke (in več) za nas. Lahko si ga predstavljate kot orodje za avtomatizacijo namesto kot nujnost. Ne glede na to olajša delo, zato si lahko privoščite gradnjo bloka z njim tako, da zaženete:
npx @wordpress/create-block
Namestite odvisnosti blokov
Ob predpostavki, da imate pripravljene tri datoteke, omenjene v prejšnjem razdelku, je čas, da namestite odvisnosti. Najprej moramo določiti odvisnosti, ki jih bomo potrebovali. To naredimo z urejanjem package.json. Med uporabo @wordpress/create-block se za nas ustvari naslednje (dodani komentarji; JSON ne podpira komentarjev, zato odstranite komentarje, če kopirate kodo):
{
// Defines the name of the project
"name": "block-example",
// Sets the project version number using semantic versioning
"version": "0.1.0",
// A brief description of the project
"description": "Example block scaffolded with Create Block tool.",
// You could replace this with yourself
"author": "The WordPress Contributors",
// Standard licensing information
"license": "GPL-2.0-or-later",
// Defines the main JavaScript file
"main": "build/index.js",
// Everything we need for building and compiling the plugin during development
"scripts": {
"build": "wp-scripts build",
"format": "wp-scripts format",
"lint:css": "wp-scripts lint-style",
"lint:js": "wp-scripts lint-js",
"packages-update": "wp-scripts packages-update",
"plugin-zip": "wp-scripts plugin-zip",
"start": "wp-scripts start"
},
// Defines which version of the scripts packages are used (24.1.0 at time of writing)
// https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/
"devDependencies": {
"@wordpress/scripts": "^24.1.0"
}
}
O @wordpress/scripts paket je tukaj glavna odvisnost. Kot lahko vidite, je a devDependency kar pomeni, da pomaga pri razvoju. Kako to? Izpostavlja wp-scripts binary, ki ga lahko uporabimo za prevajanje naše kode, iz src imenik v build imenik med drugim.
Obstajajo številni drugi paketi, ki jih WordPress vzdržuje za različne namene. Na primer, @wordpress/components paket zagotavlja več montažnih UI deli za urejevalnik blokov WordPress, ki se lahko uporablja za ustvarjanje dosledne uporabniške izkušnje za vaš blok, ki je v skladu s standardi oblikovanja WordPress.
Pravzaprav ne potrebujemo za namestitev teh paketov, tudi če jih želite uporabljati. To je zato, ker te @wordpress odvisnosti niso združene z vašo kodo bloka. Namesto tega kateri koli import izjave, ki se sklicujejo na kodo iz paketov pripomočkov - na primer @wordpress/components — se med prevajanjem uporabljajo za izdelavo datoteke »sredstev«. Poleg tega se ti uvozni stavki pretvorijo v stavke, ki preslikajo uvoze v lastnosti globalnega objekta. na primer import { __ } from "@wordpress/i18n" se pretvori v pomanjšano različico const __ = window.wp.i18n.__. (window.wp.i18n objekt, za katerega je zajamčeno, da bo na voljo v globalnem obsegu, ko bo ustrezen i18n datoteka paketa je v čakalni vrsti).
Med registracijo bloka v datoteki vtičnika se datoteka »assets« implicitno uporabi za sporočanje WordPressu odvisnosti paketa za blok. Te odvisnosti se samodejno postavijo v čakalno vrsto. Za vse to je poskrbljeno v zakulisju, pod pogojem, da uporabljate scripts paket. Kljub temu se lahko še vedno odločite za lokalno namestitev odvisnosti za dokončanje kode in podatke o parametrih v package.json datoteka:
Zdaj, ko package.json je nastavljen, bi morali biti sposobni namestiti vse te odvisnosti tako, da se pomaknemo do mape projekta v ukazni vrstici in zaženemo npm install.
Kako začeti z razvojem blokov WordPress
Dodajte glavo vtičnika
Če izhajate iz klasičnega razvoja vtičnikov WordPress, potem verjetno veste, da imajo vsi vtičniki blok informacij v glavni datoteki vtičnikov, ki WordPressu pomaga prepoznati vtičnik in prikazati informacije o njem na zaslonu vtičnikov skrbnika WordPressa.
Tukaj je kaj @wordpress/create-block ustvarjen zame v dodatku, kreativno imenovanem »Hello World«:
<?php
/**
* Plugin Name: Block Example
* Description: Example block scaffolded with Create Block tool.
* Requires at least: 5.9
* Requires PHP: 7.0
* Version: 0.1.0
* Author: The WordPress Contributors
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*
* @package create-block
*/
To je v glavni datoteki vtičnika, ki jo lahko imenujete, kakor koli želite. Lahko bi temu rekli nekako generično index.php or plugin.php. create-block paket ga samodejno pokliče, karkoli navedete kot ime projekta, ko ga namestite. Ker sem ta primer poimenoval »Primer bloka«, nam je paket dal a block-example.php datoteko z vsemi temi stvarmi.
Želeli boste spremeniti nekatere podrobnosti, na primer določiti sebe za avtorja in še kaj. In vse to ni potrebno. Če bi to vrtel od "nič", bi morda izgledalo nekaj bližje temu:
<?php
/**
* Plugin Name: Block Example
* Plugin URI: https://css-tricks.com
* Description: An example plugin for learning WordPress block development.
* Version: 1.0.0
* Author: Arjun Singh
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*/
build/: ta mapa je prejela prevedena sredstva pri obdelavi datotek za produkcijsko uporabo.
node_modules: To vsebuje vse razvojne odvisnosti, ki smo jih namestili med izvajanjem npm install.
src/: Ta mapa vsebuje izvorno kodo vtičnika, ki se prevede in pošlje v build imenik. Čez nekaj časa si bomo ogledali vsako datoteko tukaj.
.editorconfig: To vsebuje konfiguracije za prilagajanje urejevalnika kode za skladnost kode.
.gitignore: To je standardna repo datoteka, ki identificira lokalne datoteke, ki jih je treba izključiti iz sledenja nadzora različic. Vaš node_modules je vsekakor treba vključiti sem.
package-lock.json: To je samodejno ustvarjena datoteka, ki vsebuje posodobitve za sledenje zahtevanim paketom, s katerimi smo namestili npm install.
Blokiraj metapodatke
Želim se poglobiti v src imenik z vami, vendar se bo najprej osredotočil samo na eno datoteko v njem: block.json. Če ste uporabili create-block , že je tam za vas; če ne, ga ustvarite. WordPress si močno prizadeva, da bi to postal standardni, kanonični način registracije bloka z zagotavljanjem metapodatkov, ki zagotavljajo kontekst WordPress za prepoznavanje bloka in njegovo upodabljanje v urejevalniku blokov.
Tukaj je kaj @wordpress/create-block ustvarjeno zame:
Pravzaprav obstaja kup različnih informacij lahko vključimo sem, toda vse, kar je dejansko potrebno, je name in title. Super minimalna različica bi lahko izgledala takole:
$schema definira oblikovanje sheme, ki se uporablja za preverjanje vsebine v datoteki. Sliši se kot obvezna stvar, vendar je popolnoma neobvezna, saj omogoča podpornim urejevalnikom kode, da potrdijo sintakso in zagotovijo druge dodatne možnosti, kot so namigi orodnih namigov in samodejno dokončanje.
apiVersion se nanaša na to, katero različico Blok API vtičnik uporablja. Danes je različica 2 najnovejša.
name je obvezen edinstveni niz, ki pomaga identificirati vtičnik. Upoštevajte, da sem temu dodal predpono css-tricks/ ki ga uporabljam kot imenski prostor, da se izognem sporom z drugimi vtičniki, ki bi lahko imeli isto ime. Namesto tega se lahko odločite za nekaj podobnega vašim začetnicam (npr as/block-example).
version je nekaj WordPress predlaga uporabo kot mehanizem za prekinitev predpomnilnika, ko so izdane nove različice.
title je drugo obvezno polje in nastavi ime, ki se uporablja, kjer koli je prikazan vtičnik.
category združi blok z drugimi bloki in jih skupaj prikaže v urejevalniku blokov. Trenutno obstoječe kategorije vključujejo text, media, design, widgets, themein embed, in lahko celo ustvarite kategorije po meri.
icon vam omogoča, da izberete nekaj med Knjižnica Dashicons za vizualno predstavitev vašega bloka v urejevalniku blokov. Uporabljam format-quote ikona](https://developer.wordpress.org/resource/dashicons/#format-quote), saj v tem primeru izdelujemo svoje lastne potezne citate. Lepo je, da lahko izkoristimo obstoječe ikone, namesto da bi morali ustvariti lastne, čeprav je to vsekakor mogoče.
editorScript kjer je glavna datoteka JavaScript, index.js, živi.
Registrirajte blok
Še zadnja stvar, preden se lotimo dejanske kode, in to je registracija vtičnika. Pravkar smo nastavili vse te metapodatke in potrebujemo način, da jih lahko WordPress porabi. Tako WordPress ve, kje najti vsa sredstva vtičnika, da jih lahko postavi v čakalno vrsto za uporabo v urejevalniku blokov.
Registracija bloka je dvojni postopek. Registrirati ga moramo tako v PHP kot v JavaScriptu. Za stran PHP odprite glavno datoteko vtičnika (block-example.php v tem primeru) in takoj za glavo vtičnika dodajte naslednje:
To je tisto, kar je create-block pripomoček, ustvarjen zame, zato je funkcija poimenovana tako, kot je. Lahko uporabimo drugo ime. Ključno je spet izogibanje konfliktom z drugimi vtičniki, zato je dobro, da tukaj uporabite svoj imenski prostor, da bo čim bolj edinstven:
Zakaj opozarjamo na build imenik, če je block.json z vsemi metapodatki bloka src? To je zato, ker je treba našo kodo še prevesti. The scripts paket obdela kodo iz datotek v src in postavi prevedene datoteke, uporabljene v produkciji, v build imenik, medtem ko tudi kopiranjeblock.jsondatoteka v postopku.
V redu, pojdimo na stran JavaScript pri registraciji bloka. Odpri src/index.js in poskrbite, da bo videti takole:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
Vstopamo v deželo React in JSX! To sporoča WordPressu, da:
Uvozite registerBlockType modul iz @wordpress/blocks paket.
Uvozi metapodatke iz block.json.
Uvozite Edit in Save komponente iz njihovih ustreznih datotek. Pozneje bomo v te datoteke vstavili kodo.
Registrirajte blok in uporabite Edit in Save komponente za upodabljanje bloka in shranjevanje njegove vsebine v bazo podatkov.
Kaj je z edit in save funkcije? Ena od nians razvoja blokov WordPress je razlikovanje »zadnjega konca« od »prednjega dela« in te funkcije se uporabljajo za upodabljanje vsebine bloka v tistih kontekstih, kjer edit obravnava upodabljanje v ozadju in save zapiše vsebino iz urejevalnika blokov v bazo podatkov za upodabljanje vsebine na sprednji strani spletnega mesta.
Hitri test
Opravimo lahko nekaj hitrega dela, da vidimo, da naš blok deluje v urejevalniku blokov in je upodobljen na sprednji strani. Odprimo index.js znova in uporabite edit in save funkcije za vrnitev osnovne vsebine, ki ponazarja njihovo delovanje:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
const { name } = metadata;
registerBlockType(name, {
edit: () => {
return (
"Hello from the Block Editor"
);
},
save: () => {
return (
"Hello from the front end"
);
}
});
To je v bistvu skrajšana različica iste kode, ki smo jo imeli prej, le da kažemo neposredno na metapodatke v block.json za pridobitev imena bloka in izpustili Edit in Save komponente, saj izvajamo funkcije neposredno od tu.
To lahko prevedemo z zagonom npm run build v ukazni vrstici. Po tem imamo v urejevalniku blokov dostop do bloka, imenovanega »Primer bloka«:
Če spustimo blok v področje vsebine, dobimo sporočilo, ki ga vrnemo iz edit funkcija:
Kako začeti z razvojem blokov WordPress
Če objavo shranimo in objavimo, bi morali dobiti sporočilo, ki ga vrnemo iz save funkcija, ko jo gledate na sprednji strani:
Kako začeti z razvojem blokov WordPress
Ustvarjanje bloka
Videti je, da je vse povezano! Lahko se vrnemo k temu, kar smo imeli index.js pred testom zdaj, ko smo potrdili, da stvari delujejo:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
Opazite, da edit in save funkcije so vezane na dve obstoječi datoteki v src imenik, ki @wordpress/create-block ustvarjen za nas in vključuje vse dodatne uvoze, ki jih potrebujemo v vsaki datoteki. Še pomembneje pa je, da te datoteke vzpostavljajo Edit in Save komponente, ki vsebujejo oznako bloka.
Zadnja oznaka (src/edit.js)
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Edit() {
return (
{__("Hello from the Block Editor", "block-example")}
);
}
Vidite, kaj smo počeli tam? Uvažamo rekvizite iz @wordpress/block-editor paket, ki nam omogoča ustvarjanje razredov, ki jih lahko kasneje uporabimo za oblikovanje. Uvažamo tudi __ funkcija internacionalizacije, za obravnavo prevodov.
Kako začeti z razvojem blokov WordPress
Oznaka sprednjega dela (src/save.js)
To ustvari a Save komponento in uporabili bomo približno isto stvar kot src/edit.js z nekoliko drugačnim besedilom:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Spet dobimo lep razred, ki ga lahko uporabimo v našem CSS:
Kako začeti z razvojem blokov WordPress
Styling bloki
Pravkar smo obravnavali, kako uporabiti blokovne rekvizite za ustvarjanje razredov. Berete ta članek na spletnem mestu o CSS, zato se mi zdi, da bi nekaj pogrešal, če ne bi posebej obravnavali, kako napisati sloge blokov.
Razlikovanje sprednjih in zadnjih slogov
Če pogledate na block.json v src boste našli dve polji, povezani s slogi:
editorStyle ponuja pot do slogov, uporabljenih v zadnjem delu.
style je pot za sloge v skupni rabi, ki se uporabljajo za sprednji in zadnji konec.
Kev Quirk ima podroben članek ki prikazuje njegov pristop k temu, da je zaledni urejevalnik videti kot sprednji uporabniški vmesnik.
Spomnimo se, da @wordpress/scripts paket kopije block.json datoteko, ko obdeluje kodo v /src imenik in postavi zbrana sredstva v /build imenik. Je build/block.json datoteko, ki se uporablja za registracijo bloka. To pomeni katero koli pot, ki jo nudimo src/block.json mora biti zapisano glede na build/block.json.
Uporaba Sass
Lahko bi spustili nekaj datotek CSS v build imenik, sklicevanje na poti v src/block.json, zaženi gradnjo in zaključi. Vendar to ne izkoristi celotne moči @wordpress/scripts postopek prevajanja, ki je sposoben prevesti Sass v CSS. Namesto tega svoje slogovne datoteke postavimo v src in jih uvozite v JavaScript.
Pri tem moramo biti pozorni na to, kako @wordpress/scripts slogi procesov:
Datoteka z imenom style.css or style.scss or style.sass, uvožen v kodo JavaScript, je preveden v style-index.css.
Vse druge slogovne datoteke so prevedene in povezane v paket index.css.
O @wordpress/scripts uporaba paketov spletni nabor za združevanje in @wordpress/scripts uporablja vtičnik PostCSS za delo za sloge obdelave. PostCSS je mogoče razširiti z dodatnimi vtičniki. The scripts paket uporablja tiste za Sass, SCSS in Autoprefixer, ki so vsi na voljo za uporabo brez namestitve dodatnih paketov.
Pravzaprav, ko zavrtite začetni blok z @wordpress/create-block, dobite dober začetek z datotekami SCSS, ki jih lahko uporabite za začetek:
editor.scss vsebuje vse sloge, ki se uporabljajo za zaledni urejevalnik.
style.scss vsebuje vse sloge, ki si jih delita sprednji in zadnji del.
Poglejmo zdaj ta pristop v akciji, tako da napišemo malo Sass, ki ga bomo prevedli v CSS za naš blok. Čeprav primeri ne bodo zelo drzni, jih še vedno zapisujem v datoteke SCSS, da pokažem postopek prevajanja.
spredaj in zaledni slogi
V redu, začnimo s slogi, ki se uporabljajo za sprednji in zadnji del. Najprej moramo ustvariti src/style.scss (je že tam, če uporabljate @wordpress/create-block) in se prepričajte, da ga uvozimo, kar lahko storimo v index.js:
import "./style.scss";
Odpri src/style.scss in tja spustimo nekaj osnovnih slogov z uporabo razreda, ki je bil za nas ustvarjen iz blokovnih rekvizitov:
To je to za zdaj! Ko zaženemo gradnjo, se to prevede v build/style.css in nanj se sklicujeta urejevalnik blokov in sprednji del.
Zaledni slogi
Morda boste morali napisati sloge, ki so specifični za urejevalnik blokov. Za to ustvarite src/editor.scss (ponovno, @wordpress/create-block naredi to namesto vas) in tja spustite nekaj stilov:
Nato ga uvozite edit.js, ki je datoteka, ki vsebuje naše Edit komponento (lahko jo uvozimo kamorkoli želimo, a ker so ti slogi za urejevalnik, je bolj logično uvoziti komponento tukaj):
import "./editor.scss";
Zdaj, ko tečemo npm run build, sta sloga uporabljena za blok v obeh kontekstih:
Kako začeti z razvojem blokov WordPressKako začeti z razvojem blokov WordPress
Sklicevanje na sloge v block.json
Datoteke za oblikovanje smo uvozili v edit.js in index.js, vendar ne pozabite, da korak prevajanja ustvari dve datoteki CSS za nas v build imenik: index.css in style-index.css oz. Na te ustvarjene datoteke se moramo sklicevati v metapodatkih bloka.
Run npm run build še enkrat namestite in aktivirajte vtičnik na svojem spletnem mestu WordPress in pripravljeni ste za uporabo!
Lahko uporabite npm run start za zagon gradnje v načinu opazovanja, samodejno prevajanje kode vsakič, ko spremenite kodo in shranite.
Praskamo po površini
Dejanski bloki uporabljajo stransko vrstico z nastavitvami urejevalnika blokov in druge funkcije, ki jih ponuja WordPress za ustvarjanje bogate uporabniške izkušnje. Še več, dejstvo, da v bistvu obstajata dve različici našega bloka — edit in save — razmisliti morate tudi o tem, kako organizirate svojo kodo, da preprečite podvajanje kode.
Vendar upajmo, da to pomaga demistificirati splošni postopek za ustvarjanje blokov WordPress. To je resnično nova doba v razvoju WordPressa. Težko se je naučiti novih načinov dela, vendar se veselim, da bom videl, kako se bo to razvijalo. Orodja kot @wordpress/create-block pomoč, vendar je tudi takrat dobro vedeti, kaj točno počne in zakaj.
Ali se bodo stvari, ki smo jih obravnavali tukaj, spremenile? Najverjetneje! Vendar imate vsaj izhodišče za delo, medtem ko nenehno opazujemo, kako bloki WordPress zorijo, vključno z najboljšimi praksami za njihovo izdelavo.
Reference
Tudi tukaj je moj cilj začrtati učinkovito pot za vstop v razvoj blokov v tej sezoni, ko se stvari hitro razvijajo in dokumentacija WordPress težko dohaja. Tukaj je nekaj virov, ki sem jih uporabil, da sem to združil:
