Lad os erkende, at det er mærkeligt at udvikle til WordPress lige nu. Uanset om du er ny til WordPress eller har arbejdet med det i evigheder, vil introduktionen af "Full-Site Editing" (FSE) funktioner, herunder Bloker editor (WordPress 5.0) og Site Editor (WordPress 5.9), har forbedret den traditionelle måde, vi bygger WordPress-temaer og plugins på.
Selvom det er fem år siden, vi mødte Block Editoren for første gang, er det svært at udvikle til den, fordi dokumentationen enten mangler eller er forældet. Det er mere et udsagn om, hvor hurtigt FSE-funktionerne bevæger sig, noget Geoff beklagede i et nyligt indlæg.
Eksempel: I 2018 blev en indledende serie om at komme ind i Gutenberg-udvikling blev offentliggjort lige her på CSS-tricks. Tiderne har ændret sig siden da, og selvom den udviklingsstil stadig fungerer, er den det ikke anbefalet længere (foruden create-guten-block projekt, den er baseret på, vedligeholdes heller ikke længere).
I denne artikel har jeg til hensigt at hjælpe dig i gang med WordPress blokudvikling på en måde, der følger den nuværende metodik. Så ja, tingene kan sagtens ændre sig efter dette er offentliggjort. Men jeg vil prøve at fokusere på det på en måde, der forhåbentlig fanger essensen af blokudvikling, for selvom værktøjerne kan udvikle sig over tid, vil kerneideerne sandsynligvis forblive de samme.
Lad os starte med at lufte lidt forvirring med, hvad vi mener med udtryk som klodser. Al den udvikling, der gik ind i disse funktioner, der førte til WordPress 5.0, fik kodenavnet "Gutenberg” — du ved, opfinderen af trykpresse.
Siden da er "Gutenberg" blevet brugt til at beskrive alt relateret til blokeringer, inklusive Block Editor og Site Editor, så det er blevet indviklet i den grad, at nogle mennesker foragte navnet. For at toppe det hele er der en Gutenberg plugin hvor eksperimentelle funktioner testes for mulig inklusion. Og hvis du tror, at kalde alt dette for "Redigering på hele webstedet" ville løse problemet, der er også bekymringer med det.
Så når vi henviser til "blokke" i denne artikel, mener vi komponenter til at skabe indhold i WordPress Block Editor. Blokke indsættes i en side eller et indlæg og giver strukturen for en bestemt type indhold. WordPress leveres med en håndfuld "kerne"-blokke til almindelige indholdstyper, såsom afsnit, liste, billede, video og lyd, for at nævne et par stykker.
Ud over disse kerneblokke kan vi også oprette brugerdefinerede blokke. Det er, hvad WordPress blokudvikling handler om (der er også filtrering af kerneblokke for at ændre deres funktionalitet, men det har du sandsynligvis ikke brug for endnu).
Hvad blokke gør
Før vi dykker ned i at skabe blokke, skal vi først få en fornemmelse af, hvordan blokke fungerer internt. Det vil helt sikkert spare os for en masse frustration senere.
Den måde, jeg kan lide at tænke om en blok på, er ret abstrakt: for mig er en blok en entitet med nogle egenskaber (kaldet attributter), der repræsenterer noget indhold. Jeg ved godt, at det lyder ret vagt, men bliv hos mig. En blok manifesterer sig grundlæggende på to måder: som en grafisk grænseflade i blokeditoren eller som en del af data i databasen.
Når du åbner WordPress Block Editor og indsætter en blok, f.eks. en Pullquote-blok, får du en fin grænseflade. Du kan klikke ind på denne grænseflade og redigere den citerede tekst. Panelet Indstillinger til højre for Block Editor UI giver muligheder for at justere teksten og indstille blokkens udseende.
Når du er færdig med at oprette dit fancy pullquote og trykker på Publicer, bliver hele indlægget gemt i databasen i wp_posts bord. Dette er ikke noget nyt på grund af Gutenberg. Sådan har tingene altid fungeret - WordPress gemmer postindhold i en udpeget tabel i databasen. Men det nye er det en repræsentation af Pullquote-blokken er en del af indholdet, der bliver gemt i post_content felt af wp_posts tabel.
Hvordan ser denne repræsentation ud? Tag et kig:
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
Det ligner almindelig HTML, ikke?! Dette er i teknisk sprogbrug den "serialiserede" blok. Bemærk JSON-dataene i HTML-kommentaren, "textAlign": "right". Det er en egenskab - en ejendom tilknyttet blokken.
Lad os sige, at du lukker Block Editor, og derefter et stykke tid senere, åbner den igen. Indholdet fra den relevante post_content feltet hentes af blokeditoren. Redaktøren analyserer derefter det hentede indhold, og hvor som helst det støder på dette:
...
… siger den højt til sig selv:
OK, det virker som en Pullquote-blok for mig. Hmm.. den har også en attribut... Jeg har en JavaScript-fil, der fortæller mig, hvordan man konstruerer den grafiske grænseflade til en Pullquote-blok i editoren ud fra dens attributter. Det burde jeg gøre nu for at gøre denne blok i al sin herlighed.
Som blokudvikler er din opgave at:
Fortæl WordPress, at du ønsker at registrere en bestemt type blokering, med så-og-så-detaljer.
Giv JavaScript-filen til Block Editor, som hjælper den med at gengive blokken i editoren, mens den også "serialiserer" den for at gemme den i databasen.
Angiv eventuelle yderligere ressourcer, som blokken har brug for til dens korrekte funktionalitet, f.eks. typografier og skrifttyper.
En ting at bemærke er, at al denne konvertering fra serialiserede data til grafisk grænseflade - og omvendt - kun finder sted i Block Editor. På frontenden vises indholdet nøjagtigt som det er gemt. Derfor er blokke på en måde en fancy måde at lægge data i databasen på.
Forhåbentlig giver dette dig lidt klarhed over, hvordan en blok fungerer.
Kom godt i gang med WordPress Block Development
Blokke er bare plugins
Blokke er bare plugins. Nå, teknisk set dig kan sæt blokke i temaer og dig kan sæt flere blokke i et plugin. Men oftere end ikke, hvis du vil lave en blokering, laver du et plugin. Så hvis du nogensinde har oprettet et WordPress-plugin, så er du allerede på vej til at have styr på at lave en WordPress-blokering.
Men lad os et øjeblik antage, at du aldrig har opsat et WordPress-plugin, endsige en blokering. Hvor starter du overhovedet?
Opsætning af en blok
Vi har dækket, hvad blokke er. Lad os begynde at sætte tingene op for at lave en.
Sørg for, at du har Node installeret
Dette vil give dig adgang til npm , npx kommandoer, hvor npm installerer din bloks afhængigheder og hjælper med at kompilere ting, mens npx kører kommandoer på pakker uden at installere dem. Hvis du er på macOS, har du sandsynligvis allerede Node og kan bruge nvm at opdatere versioner. Hvis du er på Windows, bliver du nødt til det download og installer Node.
Opret en projektmappe
Nu kan du løbe ind i andre tutorials, der springer direkte ind på kommandolinjen og instruerer dig i at installere en pakke kaldet @wordpress/create-block. Denne pakke er fantastisk, fordi den spytter en fuldt udformet projektmappe ud med alle de afhængigheder og værktøjer, du har brug for for at begynde at udvikle.
Jeg går personligt denne vej, når jeg opretter mine egne blokke, men humor mig et øjeblik, fordi jeg ønsker at skære igennem de meningsfulde ting, det introducerer og kun fokusere på de nødvendige bits for at forstå det grundlæggende udviklingsmiljø.
Dette er de filer, jeg specifikt vil kalde frem:
readme.txt: Dette er lidt ligesom forsiden af plugin-biblioteket, der typisk bruges til at beskrive plugin'et og give yderligere detaljer om brug og installation. Hvis du sender din blokering til WordPress Plugin Directory, hjælper denne fil med at udfylde plugin-siden. Hvis du planlægger at oprette en GitHub-repo til dit blok-plugin, kan du måske også overveje en README.md fil med de samme oplysninger, så det vises pænt der.
package.json: Dette definerer de nodepakker, der kræves til udvikling. Vi slår den op, når vi kommer til installationen. I klassisk WordPress plugin-udvikling er du måske vant til at arbejde med Composer og en composer.json fil i stedet for. Dette svarer til det.
plugin.php: Dette er den primære plugin-fil, og ja, det er klassisk PHP! Vi sætter vores plugin-header og metadata her og bruger dem til at registrere plugin'et.
Ud over disse filer er der også src mappe, som formodes at indeholde kildekoden til vores blok.
At have disse filer og src bibliotek er alt hvad du behøver for at komme i gang. Ud af den gruppe, læg mærke til det vi har teknisk set kun brug for én fil (plugin.php) for at lave plugin'et. Resten giver enten information eller bruges til at styre udviklingsmiljøet.
Den førnævnte @wordpress/create-block pakke stilladser disse filer (og mere) for os. Du kan tænke på det som et automatiseringsværktøj i stedet for en nødvendighed. Uanset hvad gør det arbejdet lettere, så du kan tage dig friheden til at stilladsere en blok med den ved at køre:
npx @wordpress/create-block
Installer blokafhængigheder
Forudsat at du har de tre filer, der er nævnt i det foregående afsnit klar, er det tid til at installere afhængighederne. Først skal vi specificere de afhængigheder, vi skal bruge. Det gør vi ved at redigere package.json. Mens du bruger @wordpress/create-block værktøj, genereres følgende til os (kommentarer tilføjet; JSON understøtter ikke kommentarer, så fjern kommentarerne, hvis du kopierer koden):
{
// 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"
}
}
@wordpress/scripts pakken er den vigtigste afhængighed her. Som du kan se, er det en devDependency hvilket betyder, at det hjælper med udviklingen. Hvordan det? Det afslører wp-scripts binær, som vi kan bruge til at kompilere vores kode, fra src bibliotek til build vejviser blandt andet.
Der er en række andre pakker, som WordPress vedligeholder til forskellige formål. For eksempel @wordpress/components pakken giver flere præfabrikerede UI komponenter til WordPress Block Editor, der kan bruges til at skabe ensartede brugeroplevelser for din blok, der stemmer overens med WordPress designstandarder.
Det gør du faktisk ikke har brug for at installere disse pakker, selvom du vil bruge dem. Dette er fordi disse @wordpress afhængigheder er ikke bundtet med din blokkode. I stedet, evt import udsagn, der refererer til kode fra hjælpepakker - f.eks @wordpress/components - bruges til at konstruere en "aktiver" fil under kompilering. Desuden konverteres disse importudsagn til udsagn, der kortlægger importen til egenskaber for et globalt objekt. For eksempel, import { __ } from "@wordpress/i18n" er konverteret til en minificeret version af const __ = window.wp.i18n.__. (window.wp.i18n være et objekt, der med garanti er tilgængeligt i det globale omfang, når det tilsvarende i18n pakkefilen er sat i kø).
Under blokregistrering i plugin-filen bruges "aktiver"-filen implicit til at fortælle WordPress pakkeafhængighederne for blokken. Disse afhængigheder sættes automatisk i kø. Alt dette bliver taget hånd om bag kulisserne, givet at du bruger scripts pakke. Når det er sagt, kan du stadig vælge at lokalt installere afhængigheder til kodefuldførelse og parameterinfo i din package.json fil:
Nu hvor package.json er sat op, burde vi være i stand til at installere alle disse afhængigheder ved at navigere til projektmappen på kommandolinjen og køre npm install.
Kom godt i gang med WordPress Block Development
Tilføj plugin-headeren
Hvis du kommer fra klassisk WordPress plugin-udvikling, så ved du sikkert, at alle plugins har en blok af information i hovedplugin-filen, der hjælper WordPress med at genkende plugin'et og vise information om det på plugins-skærmen hos WordPress-administratoren.
Her er hvad @wordpress/create-block genereret til mig i et plugin kreativt kaldet "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
*/
Det er i hovedplugin-filen, som du kan kalde, hvad du vil. Du kan kalde det noget generisk som index.php or plugin.php. Det create-block pakken kalder det automatisk, hvad end du angiver som projektnavn, når du installerer det. Da jeg kaldte dette eksempel "Blokeksempel", gav pakken os en block-example.php fil med alle disse ting.
Du får lyst til at ændre nogle af detaljerne, som at gøre dig selv til forfatter og hvad der ikke kan. Og ikke alt det er nødvendigt. Hvis jeg rullede dette fra bunden, så kunne det se noget tættere på dette:
<?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
*/
Puha, det er meget! Lad os kalde de nye ting frem:
build/: Denne mappe modtog de kompilerede aktiver, da filerne blev behandlet til produktionsbrug.
node_modules: Dette indeholder alle de udviklingsafhængigheder, vi installerede, da vi kørte npm install.
src/: Denne mappe indeholder plugin's kildekode, der bliver kompileret og sendt til build vejviser. Vi vil se på hver af filerne her om lidt.
.editorconfig: Dette indeholder konfigurationer til at tilpasse din kodeeditor til kodekonsistens.
.gitignore: Dette er en standard repo-fil, der identificerer lokale filer, der bør udelukkes fra versionskontrolsporing. Din node_modules skal helt klart med her.
package-lock.json: Dette er en automatisk genereret fil, der indeholder til sporing af opdateringer til de påkrævede pakker, vi installerede med npm install.
Bloker metadata
Jeg vil grave i src mappe med dig, men vil først fokusere på kun én fil i den: block.json. Hvis du har brugt create-block , den er der allerede for dig; hvis ikke, gå videre og opret det. WordPress læner sig hårdt ind for at gøre dette til den standard, kanoniske måde at registrere en blok på ved at levere metadata, der giver WordPress-kontekst til både at genkende blokken og gengive den i Block Editor.
Her er hvad @wordpress/create-block genereret til mig:
Der er faktisk en en masse forskellig information vi kan inkludere her, men det eneste, der faktisk kræves, er name , title. En super minimal version kan se sådan ud:
$schema definerer skemaformateringen, der bruges til at validere indholdet i filen. Det lyder som en påkrævet ting, men det er helt valgfrit, da det giver understøttende kodeeditorer mulighed for at validere syntaksen og give andre yderligere råd, såsom tip til værktøjstip og autofuldførelse.
apiVersion henviser til, hvilken version af Bloker API plugin'et bruger. I dag er version 2 den seneste.
name er en påkrævet unik streng, der hjælper med at identificere pluginnet. Bemærk, at jeg har sat dette foran med css-tricks/ som jeg bruger som et navneområde for at hjælpe med at undgå konflikter med andre plugins, der kan have samme navn. Du kan vælge at bruge noget som dine initialer i stedet for (f as/block-example).
title er det andet obligatoriske felt, og det angiver det navn, der bruges, hvor end plugin'et vises.
category grupperer blokken med andre blokke og viser dem sammen i blokeditoren. Nuværende eksisterende kategorier omfatter text, media, design, widgets, themeog embed, og du kan endda oprette brugerdefinerede kategorier.
icon lader dig vælge noget fra Dashicons bibliotek for visuelt at repræsentere din blok i Block Editor. Jeg bruger format-quote ikon](https://developer.wordpress.org/resource/dashicons/#format-quote), da vi laver vores egen pullquote i dette eksempel. Det er rart, at vi kan udnytte eksisterende ikoner i stedet for at skulle skabe vores egne, selvom det bestemt er muligt.
editorScript er hvor den vigtigste JavaScript-fil, index.js, lever.
Registrer blokeringen
En sidste ting, før vi rammer den faktiske kode, og det er at registrere plugin'et. Vi har lige konfigureret alle de metadata, og vi har brug for en måde, hvorpå WordPress kan forbruge dem. På den måde ved WordPress, hvor man kan finde alle plugin-aktiverne, så de kan stilles i kø til brug i Block Editor.
Registrering af blokeringen er en todelt proces. Vi skal registrere det både i PHP og i JavaScript. For PHP-siden skal du åbne hovedplugin-filen (block-example.php i dette tilfælde) og tilføj følgende lige efter plugin-headeren:
Dette er hvad create-block værktøj genereret til mig, så det er derfor, funktionen hedder, som den er. Vi kan bruge et andet navn. Nøglen er igen at undgå konflikter med andre plugins, så det er en god idé at bruge dit navneområde her for at gøre det så unikt som muligt:
Hvorfor peger vi på build mappe, hvis block.json med alle blok-metadata er inde src? Det er fordi vores kode stadig mangler at blive kompileret. Det scripts pakken behandler koden fra filer i src mappe og placerer de kompilerede filer, der bruges i produktionen, i build bibliotek, mens også kopiering afblock.jsonfil i processen.
Okay, lad os gå over til JavaScript-siden for registrering af blokeringen. Åben op src/index.js og sørg for at det ser sådan ud:
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,
});
Vi går ind i React og JSX-land! Dette fortæller WordPress at:
Importer registerBlockType modul fra @wordpress/blocks pakke.
Importer metadata fra block.json.
Importer Edit , Save komponenter fra deres tilsvarende filer. Vi lægger kode ind i disse filer senere.
Registrer blokken, og brug Edit , Save komponenter til at gengive blokken og gemme dens indhold i databasen.
Hvad er der med edit , save funktioner? En af nuancerne ved WordPress-blokudvikling er at differentiere "bagenden" fra "frontenden", og disse funktioner bruges til at gengive blokkens indhold i de sammenhænge, hvor edit håndterer back-end rendering og save skriver indholdet fra Block Editor til databasen for at gengive indholdet på forsiden af webstedet.
En hurtig test
Vi kan gøre noget hurtigt for at se vores blok arbejde i Block Editor og gengivet på frontend. Lad os åbne index.js igen og brug edit , save funktioner til at returnere noget grundlæggende indhold, der illustrerer, hvordan de fungerer:
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"
);
}
});
Dette er dybest set en strippet version af den samme kode, som vi havde før, kun vi peger direkte på metadataene i block.json for at hente bloknavnet og udeladt Edit , Save komponenter, da vi kører funktionerne direkte herfra.
Vi kan kompilere dette ved at køre npm run build i kommandolinjen. Derefter har vi adgang til en blok kaldet "Blokeksempel" i blokeditoren:
Hvis vi slipper blokken i indholdsområdet, får vi den besked, vi vender tilbage fra edit fungere:
Kom godt i gang med WordPress Block Development
Hvis vi gemmer og offentliggør indlægget, bør vi få den besked, vi vender tilbage fra save funktion, når du ser det på forsiden:
Kom godt i gang med WordPress Block Development
Oprettelse af en blok
Det ser ud til, at alt er tilsluttet! Vi kan vende tilbage til det, vi havde i index.js før testen, nu hvor vi har bekræftet, at tingene fungerer:
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,
});
Bemærk at edit , save funktioner er bundet til to eksisterende filer i src mappe det @wordpress/create-block genereret til os og inkluderer alle de ekstra importer, vi har brug for i hver fil. Endnu vigtigere er det dog, at disse filer etablerer Edit , Save komponenter, der indeholder blokkens markup.
Opmærkning på bagsiden (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")}
);
}
Se hvad vi lavede der? Vi importerer rekvisitter fra @wordpress/block-editor pakke, som giver os mulighed for at generere klasser, vi senere kan bruge til styling. Vi importerer også __ internationaliseringsfunktion, til håndtering af oversættelser.
Kom godt i gang med WordPress Block Development
Front-end markup (src/save.js)
Dette skaber en Save komponent, og vi kommer til at bruge stort set det samme som src/edit.js med lidt anderledes tekst:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Igen får vi en fin klasse, vi kan bruge i vores CSS:
Kom godt i gang med WordPress Block Development
Styling blokke
Vi har lige dækket, hvordan man bruger blokrekvisitter til at oprette klasser. Du læser denne artikel på et websted, der handler om CSS, så jeg føler, at jeg ville mangle noget, hvis vi ikke specifikt adresserede, hvordan man skriver blokstile.
Forskellige front- og back-end-stile
Hvis du tager et kig på block.json i src bibliotek finder du to felter relateret til stilarter:
editorStyle giver stien til de stilarter, der anvendes på bagenden.
style er stien til delte stilarter, der anvendes på både for- og bagenden.
Husk at @wordpress/scripts pakken kopierer block.json fil, når den behandler koden i /src bibliotek og placerer kompilerede aktiver i /build vejviser. Det er build/block.json fil, der bruges til at registrere blokeringen. Det betyder enhver vej, som vi giver ind src/block.json skal skrives i forhold til build/block.json.
Bruger Sass
Vi kunne slippe et par CSS-filer i build mappe, skal du henvise til stierne i src/block.json, kør bygningen, og kald det en dag. Men det udnytter ikke den fulde magt @wordpress/scripts kompileringsproces, som er i stand til at kompilere Sass til CSS. I stedet placerer vi vores stilfiler i src mappe og importer dem i JavaScript.
Mens vi gør det, skal vi være opmærksomme på hvordan @wordpress/scripts processer stilarter:
En fil med navnet style.css or style.scss or style.sass, importeret til JavaScript-koden, er kompileret til style-index.css.
Alle andre stilfiler er kompileret og bundtet ind i index.css.
@wordpress/scripts pakkebrug webpakke til bundtning og @wordpress/scripts anvender PostCSS plugin for at arbejde for behandlingsstile. PostCSS kan udvides med yderligere plugins. Det scripts pakken bruger dem til Sass, SCSS og Autoprefixer, som alle er tilgængelige til brug uden at installere yderligere pakker.
Faktisk, når du spin op din indledende blok med @wordpress/create-block, får du et godt forspring med SCSS-filer, du kan bruge til at komme i gang:
editor.scss indeholder alle de stilarter, der anvendes på backend-editoren.
style.scss indeholder alle de stilarter, der deles af både for- og bagenden.
Lad os nu se denne tilgang i aktion ved at skrive en lille Sass, som vi vil kompilere i CSS for vores blok. Selvom eksemplerne ikke kommer til at være særlig fede, skriver jeg dem stadig til SCSS-filerne for at demonstrere kompileringsprocessen.
Front , back-end stilarter
OK, lad os starte med stilarter, der anvendes på både for- og bagenden. Først skal vi skabe src/style.scss (det er der allerede, hvis du bruger @wordpress/create-block) og sørg for, at vi importerer det, hvilket vi kan gøre i index.js:
import "./style.scss";
Åben op src/style.scss og slip et par grundlæggende stilarter derinde ved hjælp af klassen, der blev genereret til os fra blokrekvisitterne:
Det var det for nu! Når vi kører buildet, bliver dette kompileret til build/style.css og refereres af både Block Editor og frontend.
Back-end stilarter
Du skal muligvis skrive stilarter, der er specifikke for Block Editor. Til det, skab src/editor.scss (igen, @wordpress/create-block gør dette for dig) og smid nogle styles derinde:
Importer det derefter ind edit.js, som er den fil, der indeholder vores Edit komponent (vi kan importere den hvor som helst vi vil, men da disse stilarter er til editoren, er det mere logisk at importere komponenten her):
import "./editor.scss";
Nu når vi løber npm run build, anvendes typografierne på blokken i begge sammenhænge:
Kom godt i gang med WordPress Block DevelopmentKom godt i gang med WordPress Block Development
Referencer stilarter i block.json
Vi importerede stylingfilerne i edit.js , index.js, men husk på, at kompileringstrinnet genererer to CSS-filer til os i build vejviser: index.css , style-index.css henholdsvis. Vi skal referere til disse genererede filer i blokmetadataene.
Lad os tilføje et par udsagn til block.json metadata:
Kør npm run build endnu en gang, installer og aktiver pluginnet på dit WordPress-websted, og du er klar til at bruge det!
Du kan bruge npm run start at køre din build i urtilstand, automatisk kompilering af din kode, hver gang du foretager en ændring i din kode og gemmer.
Vi ridser overfladen
Faktiske blokeringer gør brug af Block Editor's Settings-sidebjælken og andre funktioner, som WordPress tilbyder for at skabe rige brugeroplevelser. Desuden er det faktum, at der i det væsentlige er to versioner af vores blok — edit , save — Du skal også tænke over, hvordan du organiserer din kode for at undgå kodeduplikering.
Men forhåbentlig hjælper dette med at afmystificere den generelle proces for oprettelse af WordPress-blokke. Dette er virkelig en ny æra inden for WordPress-udvikling. Det er svært at lære nye måder at gøre tingene på, men jeg glæder mig til at se, hvordan det udvikler sig. Værktøjer som @wordpress/create-block hjælp, men selv da er det rart at vide præcis, hvad det gør og hvorfor.
Vil de ting, vi dækkede her, ændre sig? Højst sandsynlig! Men du har i det mindste en baseline at arbejde ud fra, da vi bliver ved med at se WordPress-blokke modnes, herunder bedste praksis for at lave dem.
Referencer
Igen er mit mål her at kortlægge en effektiv vej til at komme ind i blokudvikling i denne sæson, hvor tingene udvikler sig hurtigt, og WordPress-dokumentationen har lidt svært ved at indhente det. Her er nogle ressourcer, jeg brugte til at samle dette:
