Låt oss erkänna att det är konstigt att utveckla för WordPress just nu. Oavsett om du är ny på WordPress eller har arbetat med det i evigheter, introduktionen av "Full-Site Editing"-funktioner (FSE), inklusive Blockredigerare (WordPress 5.0) och Webbplatsredigerare (WordPress 5.9), har förbättrat det traditionella sättet vi bygger WordPress-teman och plugins.
Även om det har gått fem år sedan vi träffade Blockeditorn för första gången är det svårt att utveckla för den eftersom dokumentationen antingen saknas eller är föråldrad. Det är mer ett uttalande om hur snabbt FSE-funktioner rör sig, något Geoff beklagade i ett nyligen inlägg.
Exempel: Under 2018, an inledande serie om att komma in i Gutenbergs utveckling publicerades här på CSS-tricks. Tiderna har förändrats sedan dess, och även om den utvecklingsstilen fortfarande fungerar, är den det rekommenderas inte längre (förutom create-guten-block projekt som den är baserad på underhålls inte längre).
I den här artikeln tänker jag hjälpa dig att komma igång med WordPress blockutveckling på ett sätt som följer den nuvarande metodiken. Så, ja, saker och ting kan mycket väl förändras efter att detta publicerats. Men jag ska försöka fokusera på det på ett sätt som förhoppningsvis fångar essensen av blockutveckling, för även om verktygen kan utvecklas med tiden, kommer kärnidéerna sannolikt att förbli desamma.
Gutenberg-redigeraren: (1) Blockinfogaren, (2) innehållsområdet och (3) sidofältet för inställningar Credit: Handbok för WordPress Block Editor
Vad är WordPress-block, exakt?
Låt oss börja med att lufta lite förvirring med vad vi menar med termer som klossar. All utveckling som gick in i dessa funktioner fram till WordPress 5.0 fick kodnamnet "Gutenberg” — du vet, uppfinnaren av tryckpress.
Sedan dess har "Gutenberg" använts för att beskriva allt som har med blockeringar att göra, inklusive Block Editor och Site Editor, så det har blivit så förvirrat att vissa människor förakta namnet. Till råga på allt finns det en Gutenberg plugin där experimentella egenskaper testas för eventuell inkludering. Och om du tror att det skulle lösa problemet att kalla allt detta för "Redigering på hela webbplatsen" det finns bekymmer med det också.
Så när vi hänvisar till "block" i den här artikeln menar vi komponenter för att skapa innehåll i WordPress Block Editor. Block infogas på en sida eller ett inlägg och ger strukturen för en viss typ av innehåll. WordPress levereras med en handfull "kärn"-block för vanliga innehållstyper, som Paragraph, List, Image, Video och Audio, för att nämna några.
Förutom dessa kärnblock kan vi också skapa anpassade block. Det är vad WordPress-blockutveckling handlar om (det finns också filtrering av kärnblock för att ändra deras funktionalitet, men du kommer förmodligen inte att behöva det ännu).
Vad block gör
Innan vi dyker in i att skapa block måste vi först få en känsla av hur block fungerar internt. Det kommer definitivt att spara oss massor av frustration senare.
Sättet jag tycker om att tänka på ett block är ganska abstrakt: för mig är ett block en entitet, med vissa egenskaper (kallade attribut), som representerar något innehåll. Jag vet att det här låter ganska vagt, men stanna med mig. Ett block manifesterar sig i princip på två sätt: som ett grafiskt gränssnitt i blockredigeraren eller som en bit av data i databasen.
När du öppnar WordPress Block Editor och infogar ett block, säg ett Pullquote-block, får du ett snyggt gränssnitt. Du kan klicka in i det gränssnittet och redigera den citerade texten. Panelen Inställningar till höger om blockredigerarens användargränssnitt ger alternativ för att justera texten och ställa in blockets utseende.
När du är klar med att skapa din snygga pullquote och trycker på Publicera, lagras hela inlägget i databasen i wp_posts tabell. Detta är inget nytt på grund av Gutenberg. Det är så saker alltid har fungerat — WordPress lagrar inläggsinnehåll i en utsedd tabell i databasen. Men det nya är det en representation av Pullquote-blocket är en del av innehållet som lagras i post_content fältet av wp_posts tabell.
Hur ser denna representation ut? Ta en titt:
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
Ser ut som vanlig HTML, eller hur?! Detta, på tekniskt språk, är det "serialiserade" blocket. Lägg märke till JSON-data i HTML-kommentaren, "textAlign": "right". Det är en attribut - en egenskap som är kopplad till blocket.
Låt oss säga att du stänger Block Editor och sedan en tid senare öppnar den igen. Innehållet från den relevanta post_content fältet hämtas av blockredigeraren. Redaktören analyserar sedan det hämtade innehållet och varhelst det stöter på detta:
...
...det säger högt för sig själv:
OK, det verkar som ett Pullquote-block för mig. Hmm... den har också ett attribut... Jag har en JavaScript-fil som talar om för mig hur man konstruerar det grafiska gränssnittet för ett Pullquote-block i editorn utifrån dess attribut. Jag borde göra det nu för att göra det här blocket i all ära.
Som blockutvecklare är ditt jobb att:
Berätta för WordPress att du vill registrera en specifik typ av block, med sid-och-så-detaljer.
Tillhandahåll JavaScript-filen till Block Editor som hjälper den att rendera blocket i editorn samtidigt som det "serialiseras" för att spara det i databasen.
Tillhandahåll eventuella ytterligare resurser som blocket behöver för korrekt funktionalitet, t.ex. stilar och typsnitt.
En sak att notera är att all denna konvertering från serialiserade data till grafiskt gränssnitt - och vice versa - endast sker i Block Editor. På fronten visas innehållet exakt som det är lagrat. Därför är block på sätt och vis ett fint sätt att lägga in data i databasen.
Förhoppningsvis ger detta dig lite klarhet i hur ett block fungerar.
Komma igång med WordPress Block Development
Block är bara plugins
Block är bara plugins. Tja, tekniskt sett, du Kan sätt block i teman och du Kan sätta flera block i ett plugin. Men oftare än inte, om du vill göra ett block, kommer du att göra ett plugin. Så om du någonsin har skapat ett WordPress-plugin, är du redan på väg att ha koll på att skapa ett WordPress-block.
Men låt oss för ett ögonblick anta att du aldrig har satt upp ett WordPress-plugin, än mindre ett block. Var börjar man ens?
Att sätta upp ett block
Vi har täckt vad block är. Låt oss börja ställa in saker för att göra en.
Se till att du har Node installerad
Detta ger dig tillgång till npm och npx kommandon, var npm installerar ditt blocks beroenden och hjälper till att kompilera saker, medan npx kör kommandon på paket utan att installera dem. Om du använder macOS har du förmodligen redan Node och kan använda nvm för att uppdatera versioner. Om du använder Windows måste du göra det ladda ner och installera Node.
Skapa en projektmapp
Nu kanske du stöter på andra handledningar som hoppar rakt in i kommandoraden och instruerar dig att installera ett paket som heter @wordpress/create-block. Det här paketet är fantastiskt eftersom det spottar ut en färdig projektmapp med alla beroenden och verktyg du behöver för att börja utveckla.
Jag personligen går den här vägen när jag sätter upp mina egna block, men humor mig ett ögonblick eftersom jag vill skära igenom de opinionsmässiga saker som det introducerar och fokusera bara på de nödvändiga bitarna för att förstå grundutvecklingsmiljön.
Dessa är filerna jag skulle vilja kalla ut specifikt:
readme.txt: Det här är ungefär som framsidan av plugin-katalogen, vanligtvis används för att beskriva plugin och ge ytterligare information om användning och installation. Om du skickar in ditt block till WordPress Plugin Directory, hjälper den här filen att fylla pluginsidan. Om du planerar att skapa en GitHub-repo för ditt blockplugin, kan du också överväga ett README.md fil med samma information så att den visas snyggt där.
package.json: Detta definierar nodpaketen som krävs för utveckling. Vi öppnar den när vi kommer till installationen. I klassisk WordPress-pluginutveckling kanske du är van vid att arbeta med Composer och en composer.json fil istället. Detta är motsvarigheten till det.
plugin.php: Detta är den huvudsakliga plugin-filen och, ja, det är klassiskt PHP! Vi lägger in vår pluginhuvud och metadata här och använder den för att registrera plugin.
Utöver dessa filer finns det också src katalog, som ska innehålla källkoden för vårt block.
Att ha dessa filer och src katalogen är allt du behöver för att komma igång. Lägg märke till det utanför den gruppen tekniskt sett behöver vi bara en fil (plugin.php) för att göra insticksprogrammet. Resten ger antingen information eller används för att hantera utvecklingsmiljön.
Den ovan nämnda @wordpress/create-block paketställningar dessa filer (och mer) åt oss. Du kan se det som ett automatiseringsverktyg istället för en nödvändighet. Oavsett vilket gör det jobbet lättare, så du kan ta dig friheten att ställa upp ett block med det genom att köra:
npx @wordpress/create-block
Installera blockberoenden
Förutsatt att du har de tre filerna som nämns i föregående avsnitt redo, är det dags att installera beroenden. Först måste vi specificera vilka beroenden vi kommer att behöva. Det gör vi genom att redigera package.json. Medan du använder @wordpress/create-block verktyget genereras följande åt oss (kommentarer tillagda; JSON stöder inte kommentarer, så ta bort kommentarerna om du kopierar 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"
}
}
Smakämnen @wordpress/scripts paketet är det huvudsakliga beroendet här. Som du kan se är det en devDependency vilket betyder att det hjälper till i utvecklingen. Hur så? Det avslöjar wp-scripts binär som vi kan använda för att kompilera vår kod, från src katalog till build katalog, bland annat.
Det finns ett antal andra paket som WordPress underhåller för olika ändamål. Till exempel @wordpress/components paketet ger flera prefab UI komponenter för WordPress Block Editor som kan användas för att skapa konsekventa användarupplevelser för ditt block som är i linje med WordPress designstandarder.
Det gör du faktiskt inte behöver för att installera dessa paket, även om du vill använda dem. Detta beror på att dessa @wordpress beroenden är inte buntade med din blockkod. Istället någon import uttalanden som refererar till kod från verktygspaket — som @wordpress/components — används för att konstruera en "tillgångar"-fil under kompileringen. Dessutom konverteras dessa importsatser till satser som mappar importen till egenskaper för ett globalt objekt. Till exempel, import { __ } from "@wordpress/i18n" konverteras till en minifierad version av const __ = window.wp.i18n.__. (window.wp.i18n är ett objekt som garanterat är tillgängligt i den globala omfattningen, när motsvarande i18n paketfilen är köad).
Under blockregistrering i plugin-filen används "tillgångar"-filen implicit för att berätta för WordPress om paketberoendena för blocket. Dessa beroenden ställs automatiskt i kö. Allt detta tas om hand bakom kulisserna, givet att du använder scripts paket. Med detta sagt kan du fortfarande välja att lokalt installera beroenden för kodkomplettering och parameterinformation i din package.json fil:
Nu när package.json är inställd, bör vi kunna installera alla dessa beroenden genom att navigera till projektmappen på kommandoraden och köra npm install.
Komma igång med WordPress Block Development
Lägg till plugin-huvudet
Om du kommer från klassisk WordPress-plugin-utveckling vet du förmodligen att alla plugin-program har ett informationsblock i huvudplugin-filen som hjälper WordPress att känna igen plugin-programmet och visa information om det på plugins-skärmen för WordPress-administratören.
Här är vad @wordpress/create-block genererade åt mig för ett plugin som kreativt heter "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 finns i huvudpluginfilen, som du kan kalla vad du vill. Du kan kalla det något generiskt som index.php or plugin.php. De create-block paketet kallar det automatiskt vad du än anger som projektnamn när du installerar det. Eftersom jag kallade det här exemplet "Blockexempel", gav paketet oss en block-example.php fil med allt det här.
Du kommer att vilja ändra några av detaljerna, som att göra dig själv till författare och sånt. Och allt detta är inte nödvändigt. Om jag rullade det här från "scratch", så kan det se något närmare det här:
<?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
*/
Vi har redan tittat på de nödvändiga filerna för vårt block. Men om du använder @wordpress/create-block, kommer du att se ett gäng andra filer i projektmappen.
build/: Den här mappen tog emot de kompilerade tillgångarna när filerna bearbetades för produktionsanvändning.
node_modules: Detta innehåller alla utvecklingsberoenden vi installerade när vi körde npm install.
src/: Den här mappen innehåller pluginens källkod som kompileras och skickas till build katalog. Vi ska titta på var och en av filerna här om en liten stund.
.editorconfig: Detta innehåller konfigurationer för att anpassa din kodredigerare för kodkonsistens.
.gitignore: Detta är en standardrepo-fil som identifierar lokala filer som bör uteslutas från versionskontrollspårning. Din node_modules borde definitivt ingå här.
package-lock.json: Detta är en automatiskt genererad fil som innehåller för att spåra uppdateringar av de nödvändiga paketen vi installerade med npm install.
Blockera metadata
Jag vill gräva i src katalog med dig men fokuserar först på bara en fil i den: block.json. Om du har använt create-block , den finns redan där för dig; om inte, fortsätt och skapa den. WordPress lutar sig hårt för att göra detta till ett standard, kanoniskt sätt att registrera ett block genom att tillhandahålla metadata som ger WordPress-kontext för att både känna igen blocket och rendera det i Block Editor.
Här är vad @wordpress/create-block skapat för mig:
Det finns faktiskt en massa olika uppgifter vi kan inkludera här, men allt som faktiskt krävs är name och title. En superminimal version kan se ut så här:
$schema definierar schemaformateringen som används för att validera innehållet i filen. Det låter som en nödvändig sak, men det är helt valfritt eftersom det tillåter stödjande kodredigerare att validera syntaxen och tillhandahålla andra ytterligare möjligheter, som tips om verktygstips och automatisk komplettering.
apiVersion hänvisar till vilken version av Blockera API plugin använder. Idag är version 2 den senaste.
name är en nödvändig unik sträng som hjälper till att identifiera plugin-programmet. Lägg märke till att jag har prefixet detta med css-tricks/ som jag använder som ett namnområde för att undvika konflikter med andra plugins som kan ha samma namn. Du kan välja att använda något som dina initialer istället (t.ex as/block-example).
title är det andra obligatoriska fältet, och det anger namnet som används varhelst plugin-programmet visas.
category grupperar blocket med andra block och visar dem tillsammans i Block Editor. Aktuella befintliga kategorier inkluderar text, media, design, widgets, themeoch embed, och du kan till och med skapa anpassade kategorier.
icon låter dig välja något från Dashicons bibliotek för att visuellt representera ditt block i Block Editor. Jag använder format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote) eftersom vi gör vår egen pullquote typ i det här exemplet. Det är trevligt att vi kan utnyttja befintliga ikoner snarare än att behöva skapa våra egna, även om det verkligen är möjligt.
editorScript är där den huvudsakliga JavaScript-filen, index.js, lever.
Registrera spärren
En sista sak innan vi träffar den faktiska koden, och det är att registrera plugin. Vi har precis ställt in all metadata och vi behöver ett sätt för WordPress att konsumera det. På så sätt vet WordPress var man kan hitta alla plugintillgångar så att de kan ställas i kö för användning i Block Editor.
Att registrera blocket är en tvåfaldig process. Vi måste registrera det både i PHP och i JavaScript. För PHP-sidan, öppna huvudpluginfilen (block-example.php i det här fallet) och lägg till följande direkt efter pluginhuvudet:
Det här är vad create-block verktyget genererat för mig, så det är därför funktionen heter som den är. Vi kan använda ett annat namn. Nyckeln är återigen att undvika konflikter med andra plugins, så det är en bra idé att använda ditt namnområde här för att göra det så unikt som möjligt:
Varför pekar vi på build katalog om block.json med all blockmetadata finns i src? Det beror på att vår kod fortfarande behöver kompileras. De scripts paketet bearbetar koden från filer i src katalogen och placerar de kompilerade filerna som används i produktionen i build katalog, medan också kopierablock.jsonfil i processen.
Okej, låt oss gå över till JavaScript-sidan för att registrera blocket. Öppna src/index.js och se till att det ser ut så här:
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 in i React och JSX-land! Detta berättar för WordPress att:
Importera registerBlockType modul från @wordpress/blocks paket.
Importera metadata från block.json.
Importera Edit och Save komponenter från deras motsvarande filer. Vi kommer att lägga in kod i de filerna senare.
Registrera blocket och använd Edit och Save komponenter för att rendera blocket och spara dess innehåll i databasen.
Vad är det med edit och save funktioner? En av nyanserna i WordPress-blockutveckling är att skilja "back end" från "front end" och dessa funktioner används för att återge blockets innehåll i de sammanhang där edit hanterar back-end-rendering och save skriver innehållet från blockredigeraren till databasen för att rendera innehållet på sidans frontend.
Ett snabbt test
Vi kan göra lite snabbt arbete för att se vårt block fungera i blockredigeraren och renderas på gränssnittet. Låt oss öppna index.js igen och använd edit och save funktioner för att returnera en del grundläggande innehåll som illustrerar hur de fungerar:
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"
);
}
});
Detta är i princip en avskalad version av samma kod som vi hade tidigare, bara vi pekar direkt på metadata i block.json för att hämta blocknamnet och utelämnade Edit och Save komponenter eftersom vi kör funktionerna direkt härifrån.
Vi kan kompilera detta genom att köra npm run build i kommandoraden. Efter det har vi tillgång till ett block som heter "Blockexempel" i Block Editor:
Om vi släpper blocket i innehållsområdet får vi meddelandet vi returnerar från edit fungera:
Komma igång med WordPress Block Development
Om vi sparar och publicerar inlägget bör vi få meddelandet vi återkommer från save funktion när du tittar på den på framsidan:
Komma igång med WordPress Block Development
Skapa ett block
Det verkar som att allt är uppkopplat! Vi kan återgå till det vi hade i index.js innan testet nu när vi har bekräftat att saker fungerar:
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,
});
Observera att edit och save funktioner är knutna till två befintliga filer i src katalog som @wordpress/create-block genereras åt oss och inkluderar alla ytterligare importer vi behöver i varje fil. Ännu viktigare är dock att dessa filer etablerar Edit och Save komponenter som innehåller blockets markering.
Markering på baksidan (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")}
);
}
Ser du vad vi gjorde där? Vi importerar rekvisita från @wordpress/block-editor paket som låter oss skapa klasser som vi senare kan använda för styling. Vi importerar också __ internationaliseringsfunktion, för att hantera översättningar.
Komma igång med WordPress Block Development
Front-end uppmärkning (src/save.js)
Detta skapar en Save komponent och vi kommer att använda ungefär samma sak som src/edit.js med lite annorlunda text:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Återigen får vi en trevlig klass som vi kan använda i vår CSS:
Komma igång med WordPress Block Development
Styling block
Vi tog precis upp hur man använder blockrekvisita för att skapa klasser. Du läser den här artikeln på en webbplats som handlar om CSS, så jag känner att jag skulle sakna något om vi inte specifikt tog upp hur man skriver blockstilar.
Skiljer på främre och bakre stilar
Om du tittar på block.json i src katalogen hittar du två fält relaterade till stilar:
editorStyle ger sökvägen till stilarna som tillämpas på baksidan.
style är sökvägen för delade stilar som tillämpas på både fram- och baksidan.
Minns att @wordpress/scripts paketet kopierar block.json fil när den bearbetar koden i /src katalog och placerar kompilerade tillgångar i /build katalog. Det är build/block.json fil som används för att registrera blocket. Det betyder vilken väg som helst som vi tillhandahåller src/block.json ska skrivas i förhållande till build/block.json.
Använder Sass
Vi kan släppa ett par CSS-filer i build katalog, referera till sökvägarna i src/block.json, kör byggnaden och ta en dag. Men det utnyttjar inte den fulla kraften @wordpress/scripts kompileringsprocess, som kan kompilera Sass till CSS. Istället placerar vi våra stilfiler i src katalog och importera dem i JavaScript.
När vi gör det måste vi vara uppmärksamma på hur @wordpress/scripts processstilar:
En fil med namnet style.css or style.scss or style.sass, som importeras till JavaScript-koden, kompileras till style-index.css.
Alla andra stilfiler kompileras och buntas in i index.css.
Smakämnen @wordpress/scripts paketet använder Webpack för buntning och @wordpress/scripts använder PostCSS-plugin för att arbeta för bearbetningsstilar. PostCSS kan utökas med ytterligare plugins. De scripts paketet använder de för Sass, SCSS och Autoprefixer, som alla är tillgängliga för användning utan att installera ytterligare paket.
Faktum är att när du snurrar upp ditt första block med @wordpress/create-block, får du ett bra försprång med SCSS-filer som du kan använda för att komma igång:
editor.scss innehåller alla stilar som tillämpas på backend-redigeraren.
style.scss innehåller alla stilar som delas av både fram- och baksidan.
Låt oss nu se detta tillvägagångssätt i praktiken genom att skriva lite Sass som vi kommer att kompilera till CSS för vårt block. Även om exemplen inte kommer att vara särskilt sass-y, skriver jag dem fortfarande till SCSS-filerna för att demonstrera kompileringsprocessen.
Front och back-end stilar
OK, låt oss börja med stilar som tillämpas på både fram- och baksidan. Först måste vi skapa src/style.scss (det finns redan där om du använder @wordpress/create-block) och se till att vi importerar det, vilket vi kan göra i index.js:
import "./style.scss";
Öppna src/style.scss och släpp några grundläggande stilar där med hjälp av klassen som skapades för oss från blockets rekvisita:
Det var allt för nu! När vi kör konstruktionen kompileras detta till build/style.css och refereras av både blockredigeraren och användargränssnittet.
Back-end stilar
Du kan behöva skriva stilar som är specifika för Block Editor. För det, skapa src/editor.scss (igen, @wordpress/create-block gör detta åt dig) och släpp några stilar där:
Importera sedan in den edit.js, vilket är filen som innehåller vår Edit komponent (vi kan importera den var som helst, men eftersom dessa stilar är för redigeraren är det mer logiskt att importera komponenten här):
import "./editor.scss";
Nu när vi springer npm run build, stilarna tillämpas på blocket i båda sammanhangen:
Komma igång med WordPress Block DevelopmentKomma igång med WordPress Block Development
Refererar till stilar i block.json
Vi importerade stylingfilerna i edit.js och index.js, men kom ihåg att kompileringssteget genererar två CSS-filer för oss i build katalogen: index.css och style-index.css respektive. Vi måste referera till dessa genererade filer i blockmetadata.
Låt oss lägga till ett par uttalanden till block.json Metadata:
Körning npm run build återigen, installera och aktivera plugin-programmet på din WordPress-webbplats, och du är redo att använda den!
Du kan använda npm run start att köra din build i klockläge, automatiskt kompilera din kod varje gång du gör en ändring i din kod och sparar.
Vi skrapar på ytan
Faktiska block använder sidofältet Block Editor's Settings och andra funktioner som WordPress tillhandahåller för att skapa rika användarupplevelser. Dessutom, det faktum att det i huvudsak finns två versioner av vårt block — edit och save — Du måste också tänka på hur du organiserar din kod för att undvika kodduplicering.
Men förhoppningsvis hjälper detta till att avmystifiera den allmänna processen för att skapa WordPress-block. Detta är verkligen en ny era inom WordPress-utveckling. Det är tufft att lära sig nya sätt att göra saker på, men jag ser fram emot att se hur det utvecklas. Verktyg som @wordpress/create-block hjälp, men även då är det skönt att veta exakt vad den gör och varför.
Kommer de saker vi behandlade här att förändras? Mest troligt! Men du har åtminstone en baslinje att arbeta utifrån när vi fortsätter att se WordPress-block mogna, inklusive bästa praxis för att göra dem.
Referensprojekt
Återigen, mitt mål här är att kartlägga en effektiv väg för att komma in i blockutveckling under den här säsongen där saker och ting utvecklas snabbt och WordPress-dokumentationen har lite svårt att komma ikapp. Här är några resurser jag använde för att få ihop detta:
