Laten we erkennen dat ontwikkelen voor WordPress op dit moment raar is. Of je nu nieuw bent bij WordPress of er al eeuwen mee werkt, de introductie van "Full-Site Editing" (FSE)-functies, inclusief de Blok-editor (WordPress 5.0) en de Site-editor (WordPress 5.9), hebben de traditionele manier waarop we WordPress-thema's en plug-ins bouwen, op zijn kop gezet.
Hoewel het vijf jaar geleden is dat we de Block Editor voor het eerst hebben ontmoet, is het moeilijk om ervoor te ontwikkelen omdat de documentatie ontbreekt of verouderd is. Dat is meer een verklaring over hoe snel FSE-functies bewegen, zoiets Geoff klaagde in een recent bericht.
Voorbeeld: in 2018, een inleidende serie over de ontwikkeling van Gutenberg werd hier op CSS-tricks gepubliceerd. De tijden zijn sindsdien veranderd, en hoewel die ontwikkelingsstijl nog steeds werkt, is het dat wel niet aanbevolen niet meer (bovendien, de create-guten-block project waarop het is gebaseerd, wordt ook niet langer onderhouden).
In dit artikel wil ik je helpen om aan de slag te gaan met de ontwikkeling van WordPress-blokken op een manier die de huidige methodologie volgt. Dus ja, dingen kunnen heel goed veranderen nadat dit is gepubliceerd. Maar ik ga proberen me erop te concentreren op een manier die hopelijk de essentie van blokontwikkeling vat, want hoewel de tools in de loop van de tijd kunnen evolueren, zullen de kernideeën waarschijnlijk hetzelfde blijven.
De Gutenberg-editor: (1) de blokinvoeger, (2) het inhoudsgebied en (3) de zijbalk met instellingen credit: WordPress Block Editor-handboek
Wat zijn WordPress-blokken precies?
Laten we beginnen met het luchten van enige verwarring over wat we bedoelen met termen als blokken. Alle ontwikkeling die naar deze functies heeft geleid in de aanloop naar WordPress 5.0 had de codenaam "Gutenberg” — je weet wel, de uitvinder van de drukpers.
Sindsdien is "Gutenberg" gebruikt om alles te beschrijven dat met blokken te maken heeft, inclusief de Block Editor en Site Editor, dus het is zo ingewikkeld geworden dat sommige mensen veracht de naam. Om het helemaal af te maken is er een Gutenberg-plug-in waar experimentele functies worden getest op mogelijke opname. En als je denkt dat het probleem zou zijn opgelost door al deze "Full-Site Editing" te noemen, daar zijn ook zorgen over.
Dus als we in dit artikel naar "blokken" verwijzen, bedoelen we componenten voor het maken van inhoud in de WordPress Block Editor. Blokken worden in een pagina of bericht ingevoegd en bieden de structuur voor een bepaald type inhoud. WordPress wordt geleverd met een handvol "kern" -blokken voor veelvoorkomende inhoudstypen, zoals alinea, lijst, afbeelding, video en audio, om er een paar te noemen.
Naast deze kernblokken kunnen we ook aangepaste blokken maken. Dat is waar de ontwikkeling van WordPress-blokken over gaat (er zijn ook filterblokken om hun functionaliteit aan te passen, maar die heb je waarschijnlijk nog niet nodig).
Wat blokken doen?
Voordat we ons verdiepen in het maken van blokken, moeten we eerst een idee krijgen van hoe blokken intern werken. Dat zal ons later zeker een hoop frustratie besparen.
De manier waarop ik graag over een blok denk, is nogal abstract: voor mij is een blok een entiteit, met enkele eigenschappen (attributen genoemd), die een bepaalde inhoud vertegenwoordigt. Ik weet dat dit nogal vaag klinkt, maar blijf bij me. Een blok manifesteert zich in principe op twee manieren: als een grafische interface in de blokeditor of als een stuk data in de database.
Wanneer je de WordPress Block Editor opent en een blok invoegt, bijvoorbeeld een Pullquote-blok, krijg je een mooie interface. U kunt in die interface klikken en de geciteerde tekst bewerken. Het paneel Instellingen aan de rechterkant van de gebruikersinterface van de Block Editor biedt opties voor het aanpassen van de tekst en het instellen van het uiterlijk van het blok.
Wanneer je klaar bent met het maken van je mooie pullquote en op Publiceren klikt, wordt het hele bericht opgeslagen in de database in de wp_posts tafel. Dit is niets nieuws vanwege Gutenberg. Zo hebben dingen altijd gewerkt: WordPress slaat inhoud van berichten op in een daarvoor bestemde tabel in de database. Maar wat nieuw is, is dat een weergave van het Pullquote-blok maakt deel uit van de inhoud die wordt opgeslagen in post_content gebied van de wp_posts tafel.
Hoe ziet deze voorstelling eruit? Even kijken:
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
Ziet eruit als gewone HTML, toch?! Dit, in technisch jargon, is het "geserialiseerde" blok. Let op de JSON-gegevens in de HTML-opmerking, "textAlign": "right". Dat is een attribuut — een eigenschap die bij het blok hoort.
Laten we zeggen dat u de Block Editor sluit en enige tijd later opnieuw opent. De inhoud van de relevante post_content veld wordt opgehaald door de Block Editor. De editor parseert vervolgens de opgehaalde inhoud, en waar hij dit ook tegenkomt:
...
... zegt het hardop tegen zichzelf:
OK, dat lijkt me een Pullquote-blok. Hmm.. het heeft ook een attribuut... Ik heb wel een JavaScript-bestand dat me vertelt hoe ik de grafische interface voor een Pullquote-blok in de editor moet bouwen op basis van zijn attributen. Ik zou dat nu moeten doen om dit blok in al zijn glorie weer te geven.
Als blokontwikkelaar is het jouw taak om:
Vertel WordPress dat je een specifiek type blok wilt registreren, met zo-en-zo details.
Geef het JavaScript-bestand aan de Block Editor waarmee het blok in de editor kan worden weergegeven, terwijl het ook wordt "serialiseren" om het in de database op te slaan.
Bied alle aanvullende bronnen die het blok nodig heeft voor de juiste functionaliteit, bijvoorbeeld stijlen en lettertypen.
Een ding om op te merken is dat al deze conversie van geserialiseerde gegevens naar grafische interface - en vice versa - alleen plaatsvindt in de Block Editor. Aan de voorkant wordt de inhoud precies weergegeven zoals deze is opgeslagen. Daarom zijn blokken in zekere zin een mooie manier om gegevens in de database te plaatsen.
Hopelijk geeft dit je wat duidelijkheid over hoe een blok werkt.
Aan de slag met WordPress Block Development
Blokken zijn slechts plug-ins
Blokken zijn slechts plug-ins. Nou, technisch gezien, jij wel zet blokken in thema's en jij wel zet meerdere blokken in een plug-in. Maar vaker wel dan niet, als je een blok wilt maken, ga je een plug-in maken. Dus als je ooit een WordPress-plug-in hebt gemaakt, dan ben je al een eind op weg om grip te krijgen op het maken van een WordPress-blok.
Maar laten we even aannemen dat je nog nooit een WordPress-plug-in hebt opgezet, laat staan een blokkering. Waar begin je eigenlijk?
Een blok opzetten
We hebben besproken wat blokken zijn. Laten we beginnen met het opzetten van dingen om er een te maken.
Zorg ervoor dat Node is geïnstalleerd
Hiermee krijgt u toegang tot npm en npx commando's, waar npm installeert de afhankelijkheden van je blok en helpt bij het compileren van dingen, terwijl npx voert opdrachten uit op pakketten zonder ze te installeren. Als je macOS gebruikt, heb je waarschijnlijk al Node en kun je gebruiken nvm om versies bij te werken. Als u Windows gebruikt, moet u: download en installeer Node.
Een projectmap maken
Nu kunt u andere tutorials tegenkomen die rechtstreeks naar de opdrachtregel springen en u instrueren om een pakket met de naam . te installeren @wordpress/create-block. Dit pakket is geweldig omdat het een volledig gevormde projectmap uitspuugt met alle afhankelijkheden en hulpmiddelen die je nodig hebt om te beginnen met ontwikkelen.
Persoonlijk ga ik deze route bij het opzetten van mijn eigen blokken, maar maak me even een grapje omdat ik de eigenzinnige dingen die het introduceert door wil snijden en me alleen op de vereiste stukjes wil concentreren om de basisontwikkelingsomgeving te begrijpen.
Dit zijn de bestanden die ik specifiek wil oproepen:
readme.txt: Dit lijkt op de voorkant van de plug-in-directory, die meestal wordt gebruikt om de plug-in te beschrijven en aanvullende details te geven over gebruik en installatie. Als u uw blokkering opstuurt naar de WordPress Plugin Directory, dit bestand helpt bij het vullen van de plug-inpagina. Als u van plan bent een GitHub-repo voor uw blokplug-in te maken, kunt u ook overwegen een: README.md bestand met dezelfde informatie, zodat het daar mooi wordt weergegeven.
package.json: Dit definieert de Node-pakketten die nodig zijn voor ontwikkeling. We zullen het openbreken als we bij de installatie zijn. Bij de ontwikkeling van klassieke WordPress-plug-ins bent u misschien gewend aan het werken met Composer en a composer.json bestand in plaats daarvan. Dit is het equivalent daarvan.
plugin.php: Dit is het belangrijkste plug-inbestand en, ja, het is klassieke PHP! We zullen onze plug-in header en metadata hier plaatsen en gebruiken om de plug-in te registreren.
Naast deze bestanden is er ook de src directory, die verondersteld wordt de broncode van ons blok te bevatten.
Met deze bestanden en de src directory is alles wat je nodig hebt om te beginnen. Buiten die groep, merk op dat we hebben technisch gezien maar één bestand nodig (plugin.php) om de plug-in te maken. De rest levert informatie of wordt gebruikt om de ontwikkelomgeving te beheren.
De bovengenoemde @wordpress/create-block package ondersteunt deze bestanden (en meer) voor ons. Je kunt het zien als een automatiseringstool in plaats van als een noodzaak. Hoe dan ook, het maakt het werk gemakkelijker, dus je kunt de vrijheid nemen om er een blok mee te maken door te rennen:
npx @wordpress/create-block
Blokafhankelijkheden installeren
Ervan uitgaande dat u de drie bestanden die in de vorige sectie zijn genoemd gereed hebt, is het tijd om de afhankelijkheden te installeren. Eerst moeten we de afhankelijkheden specificeren die we nodig hebben. Dat doen we door de package.json. Tijdens het gebruik van de @wordpress/create-block hulpprogramma, wordt het volgende voor ons gegenereerd (opmerkingen toegevoegd; JSON ondersteunt geen opmerkingen, dus verwijder de opmerkingen als u de code kopieert):
{
// 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"
}
}
De @wordpress/scripts pakket is hier de belangrijkste afhankelijkheid. Zoals je kunt zien, is het een devDependency wat betekent dat het helpt bij de ontwikkeling. Hoezo? Het onthult de wp-scripts binair dat we kunnen gebruiken om onze code te compileren, van de src map naar de build adresboek oa.
Er zijn een aantal andere pakketten die WordPress onderhoudt voor verschillende doeleinden. Bijvoorbeeld de @wordpress/components pakket biedt: meerdere prefab UI componenten voor de WordPress Block Editor die kan worden gebruikt voor het creëren van consistente gebruikerservaringen voor uw blok die zijn afgestemd op de ontwerpnormen van WordPress.
Dat doe je eigenlijk niet genoodzaakt bent om deze pakketten te installeren, zelfs als u ze wilt gebruiken. Dit komt omdat deze @wordpress afhankelijkheden zijn niet gebundeld met uw blokcode. In plaats daarvan, elke import statements die verwijzen naar code uit hulpprogrammapakketten — like @wordpress/components — worden gebruikt om een “assets”-bestand samen te stellen tijdens het compileren. Bovendien worden deze importstatements geconverteerd naar statements die de imports toewijzen aan eigenschappen van een globaal object. Bijvoorbeeld, import { __ } from "@wordpress/i18n" is geconverteerd naar een verkleinde versie van const __ = window.wp.i18n.__. (window.wp.i18n een object zijn dat gegarandeerd beschikbaar is in de globale scope, zodra de overeenkomstige i18n pakketbestand is in de wachtrij geplaatst).
Tijdens blokregistratie in het plug-inbestand wordt het "assets" -bestand impliciet gebruikt om WordPress de pakketafhankelijkheden voor het blok te vertellen. Deze afhankelijkheden worden automatisch in de wachtrij geplaatst. Dit alles wordt achter de schermen geregeld, op voorwaarde dat u de scripts pakket. Dat gezegd hebbende, kunt u er nog steeds voor kiezen om afhankelijkheden lokaal te installeren voor het voltooien van code en parameterinformatie in uw package.json file:
Nu package.json is ingesteld, zouden we al die afhankelijkheden moeten kunnen installeren door naar de projectmap in de opdrachtregel te navigeren en te starten npm install.
Aan de slag met WordPress Block Development
Voeg de plug-in-header toe
Als je afkomstig bent van de klassieke ontwikkeling van WordPress-plug-ins, dan weet je waarschijnlijk dat alle plug-ins een informatieblok in het hoofdplug-inbestand hebben dat WordPress helpt de plug-in te herkennen en informatie erover weer te geven op het plug-insscherm van de WordPress-beheerder.
Dit is wat @wordpress/create-block gegenereerd voor mij in voor een plug-in die creatief "Hello World" wordt genoemd:
<?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
*/
Dat staat in het hoofdplug-inbestand, dat je kunt noemen wat je maar wilt. Je zou het iets generieks kunnen noemen, zoals: index.php or plugin.php. De create-block package noemt het automatisch wat je ook opgeeft als de projectnaam bij het installeren ervan. Omdat ik dit voorbeeld "Blokvoorbeeld" noemde, gaf het pakket ons een block-example.php bestand met al deze dingen.
Je zult een aantal details willen veranderen, zoals jezelf de auteur maken en zo. En dat is allemaal niet nodig. Als ik dit vanaf "scratch" zou rollen, zou het er misschien iets meer op lijken:
<?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
*/
We hebben al gekeken naar de benodigde bestanden voor ons blok. Maar als je gebruikt @wordpress/create-block, ziet u een heleboel andere bestanden in de projectmap.
Pfff, dat is veel! Laten we de nieuwe dingen noemen:
build/: Deze map heeft de gecompileerde assets ontvangen bij het verwerken van de bestanden voor productiegebruik.
node_modules: Dit bevat alle ontwikkelingsafhankelijkheden die we tijdens het uitvoeren hebben geïnstalleerd npm install.
src/: Deze map bevat de broncode van de plug-in die wordt gecompileerd en verzonden naar de build map. We zullen zo even naar elk van de bestanden kijken.
.editorconfig: Dit bevat configuraties om uw code-editor aan te passen voor codeconsistentie.
.gitignore: Dit is een standaard repo-bestand dat lokale bestanden identificeert die moeten worden uitgesloten van het bijhouden van versiebeheer. Uw node_modules moet hier zeker bij horen.
package-lock.json: Dit is een automatisch gegenereerd bestand dat updates bevat voor het bijhouden van de vereiste pakketten waarmee we hebben geïnstalleerd npm install.
Metadata blokkeren
ik wil me verdiepen in de src directory met u, maar zal zich eerst concentreren op slechts één bestand erin: block.json. Als je hebt gebruikt create-block , het is er al voor je; zo niet, ga je gang en creëer het. WordPress leunt moeilijk om dit de standaard, canonieke manier te maken om een blok te registreren door metadata te leveren die WordPress-context bieden om zowel het blok te herkennen als het in de Block Editor weer te geven.
Dit is wat @wordpress/create-block voor mij gegenereerd:
Er is eigenlijk een veel verschillende informatie we kunnen hier opnemen, maar het enige dat eigenlijk nodig is, is: name en title. Een superminimale versie kan er als volgt uitzien:
$schema definieert de schema-opmaak die wordt gebruikt om de inhoud in het bestand te valideren. Het klinkt als een vereiste, maar het is volledig optioneel omdat het ondersteunende code-editors in staat stelt om de syntaxis te valideren en andere aanvullende mogelijkheden te bieden, zoals tooltip-hints en automatisch aanvullen.
apiVersion verwijst naar welke versie van de API blokkeren de plug-in gebruikt. Vandaag is versie 2 de nieuwste.
name is een vereiste unieke tekenreeks die helpt bij het identificeren van de plug-in. Merk op dat ik dit heb voorafgegaan door css-tricks/ die ik gebruik als naamruimte om conflicten met andere plug-ins met dezelfde naam te voorkomen. U kunt ervoor kiezen om in plaats daarvan iets als uw initialen te gebruiken (bijv as/block-example).
title is het andere verplichte veld en het stelt de naam in die overal wordt gebruikt waar de plug-in wordt weergegeven.
category groepeert het blok met andere blokken en geeft ze samen weer in de Block Editor. Huidige bestaande categorieën omvatten: text, media, design, widgets, theme en embed, en je kunt zelfs maken aangepaste categorieën.
icon laat je iets kiezen uit de Dashicons-bibliotheek om uw blok visueel weer te geven in de Block Editor. ik gebruik de format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote) omdat we in dit voorbeeld onze eigen pullquote-dingen maken. Het is fijn dat we bestaande pictogrammen kunnen gebruiken in plaats van onze eigen pictogrammen te moeten maken, hoewel dat zeker mogelijk is.
editorScript is waar het belangrijkste JavaScript-bestand, index.js, leeft.
Registreer het blok
Een laatste ding voordat we de daadwerkelijke code raken, en dat is om de plug-in te registreren. We hebben net al die metadata ingesteld en we hebben een manier nodig waarop WordPress deze kan gebruiken. Op die manier weet WordPress waar alle plug-ins kunnen worden gevonden, zodat ze in de wachtrij kunnen worden geplaatst voor gebruik in de Block Editor.
Het registreren van het blok is een tweeledig proces. We moeten het zowel in PHP als in JavaScript registreren. Open voor de PHP-kant het hoofdplug-inbestand (block-example.php in dit geval) en voeg het volgende toe direct na de plug-in-header:
Dit is wat de create-block hulpprogramma dat voor mij is gegenereerd, dus daarom heet de functie zoals hij is. We kunnen een andere naam gebruiken. De sleutel, nogmaals, is het vermijden van conflicten met andere plug-ins, dus het is een goed idee om uw naamruimte hier te gebruiken om deze zo uniek mogelijk te maken:
Waarom wijzen we naar de build map als de block.json met alle blokmetadata is in src? Dat komt omdat onze code nog moet worden gecompileerd. De scripts pakket verwerkt de code van bestanden in de src directory en plaatst de gecompileerde bestanden die bij de productie worden gebruikt in de build directory, terwijl ook het kopiëren van deblock.jsonfilet in het proces.
Oké, laten we overgaan naar de JavaScript-kant van het registreren van het blok. open doen src/index.js en zorg ervoor dat het er zo uitziet:
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,
});
We komen in React en JSX land! Dit vertelt WordPress om:
Importeer de registerBlockType module van de @wordpress/blocks pakket.
Metadata importeren uit block.json.
Importeer de Edit en Save componenten uit hun corresponderende bestanden. We zullen later code in die bestanden plaatsen.
Registreer het blok, en gebruik de Edit en Save componenten voor het renderen van het blok en het opslaan van de inhoud in de database.
Wat is er met de edit en save functies? Een van de nuances van de ontwikkeling van WordPress-blokken is het onderscheiden van de "back-end" van de "front-end" en deze functies worden gebruikt om de inhoud van het blok in die contexten weer te geven, waar edit zorgt voor back-end rendering en save schrijft de inhoud van de Block Editor naar de database om de inhoud aan de voorkant van de site weer te geven.
Een snelle test
We kunnen wat snel werk doen om ons blok te zien werken in de Block Editor en weergegeven aan de voorkant. Laten we openen index.js opnieuw en gebruik de edit en save functies om wat basisinhoud terug te geven die illustreert hoe ze werken:
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"
);
}
});
Dit is in feite een uitgeklede versie van dezelfde code die we eerder hadden, alleen verwijzen we rechtstreeks naar de metadata in block.json om de bloknaam op te halen, en liet de . weg Edit en Save componenten omdat we de functies rechtstreeks vanaf hier uitvoeren.
We kunnen dit compileren door te draaien npm run build in de opdrachtregel. Daarna hebben we toegang tot een blok met de naam "Blokvoorbeeld" in de Block Editor:
Als we het blok in het inhoudsgebied laten vallen, krijgen we het bericht dat we terugkrijgen van de edit functie:
Aan de slag met WordPress Block Development
Als we het bericht opslaan en publiceren, zouden we het bericht moeten krijgen dat we terugkrijgen van de save functie wanneer u deze aan de voorkant bekijkt:
Aan de slag met WordPress Block Development
Een blok maken
Zo te zien is alles aangesloten! We kunnen terug naar wat we hadden in index.js voor de test nu we hebben bevestigd dat alles werkt:
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,
});
Merk op dat de edit en save functies zijn gekoppeld aan twee bestaande bestanden in de src directory dat @wordpress/create-block voor ons gegenereerd en bevat alle extra invoer die we nodig hebben in elk bestand. Wat nog belangrijker is, is dat die bestanden de Edit en Save componenten die de opmaak van het blok bevatten.
Back-end opmaak (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")}
);
}
Zie je wat we daar deden? We importeren rekwisieten uit de @wordpress/block-editor pakket waarmee we klassen kunnen genereren die we later voor styling kunnen gebruiken. We importeren ook de __ internationaliseringsfunctie, voor het omgaan met vertalingen.
Aan de slag met WordPress Block Development
Front-end opmaak (src/save.js)
Dit creëert een Save component en we gaan ongeveer hetzelfde gebruiken als src/edit.js met iets andere tekst:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Nogmaals, we krijgen een mooie klasse die we in onze CSS kunnen gebruiken:
Aan de slag met WordPress Block Development
Stylingblokken
We hebben zojuist besproken hoe je blokrekwisieten kunt gebruiken om klassen te maken. Je leest dit artikel op een site over CSS, dus ik heb het gevoel dat ik iets zou missen als we niet specifiek zouden ingaan op het schrijven van blokstijlen.
Differentiatie van front- en back-endstijlen
Als je het block.json in de src directory vindt u twee velden met betrekking tot stijlen:
editorStyle biedt het pad naar de stijlen die op de backend zijn toegepast.
style is het pad voor gedeelde stijlen die worden toegepast op zowel de voorkant als de achterkant.
Bedenk dat het @wordpress/scripts pakket kopieert de block.json bestand wanneer het de code verwerkt in de /src directory en plaatst gecompileerde assets in de /build map. Het is de build/block.json bestand dat wordt gebruikt om het blok te registreren. Dat betekent dat elk pad dat we bieden in src/block.json moet worden geschreven ten opzichte van build/block.json.
Sass gebruiken
We kunnen een paar CSS-bestanden in de build directory, verwijs naar de paden in src/block.json, voer de build uit en noem het een dag. Maar dat maakt geen gebruik van de volledige macht van de @wordpress/scripts compilatieproces, waarmee Sass in CSS kan worden gecompileerd. In plaats daarvan plaatsen we onze stijlbestanden in de src directory en importeer ze in JavaScript.
Terwijl we dat doen, moeten we ons bewust zijn van hoe @wordpress/scripts processen stijlen:
Een bestand met de naam style.css or style.scss or style.sass, geïmporteerd in de JavaScript-code, wordt gecompileerd om style-index.css.
Alle andere stijlbestanden worden gecompileerd en gebundeld in index.css.
De @wordpress/scripts pakket gebruikt webpack voor bundelen en @wordpress/scripts gebruikt PostCSS-plug-in voor het werken voor verwerkingsstijlen. PostCSS kan worden uitgebreid met extra plug-ins. De scripts pakket gebruikt die voor Sass, SCSS en Autoprefixer, die allemaal beschikbaar zijn voor gebruik zonder extra pakketten te installeren.
Sterker nog, als je je eerste blok laat draaien met @wordpress/create-block, krijg je een mooie voorsprong met SCSS-bestanden die je kunt gebruiken om aan de slag te gaan:
editor.scss bevat alle stijlen die worden toegepast op de back-end-editor.
style.scss bevat alle stijlen die worden gedeeld door zowel de voorkant als de achterkant.
Laten we deze aanpak nu in actie zien door een beetje Sass te schrijven dat we in de CSS voor ons blok zullen compileren. Hoewel de voorbeelden niet erg Sass-y zullen zijn, schrijf ik ze nog steeds naar de SCSS-bestanden om het compilatieproces te demonstreren.
Voorwiel en back-end stijlen
Oké, laten we beginnen met stijlen die zowel aan de voorkant als aan de achterkant worden toegepast. Eerst moeten we creëren src/style.scss (het is er al als je gebruikt @wordpress/create-block) en zorg ervoor dat we het importeren, wat we kunnen doen in index.js:
import "./style.scss";
Open src/style.scss en laat daar een paar basisstijlen vallen met behulp van de klasse die voor ons is gegenereerd vanuit de blokrekwisieten:
Dat is het voor nu! Wanneer we de build uitvoeren, wordt dit gecompileerd in build/style.css en er wordt naar verwezen door zowel de Block Editor als de front-end.
Back-end stijlen
Mogelijk moet u stijlen schrijven die specifiek zijn voor de Block Editor. Maak daarvoor src/editor.scss (nog een keer, @wordpress/create-block doet dit voor je) en laat daar wat stijlen in:
Importeer het dan in edit.js, dat is het bestand dat onze . bevat Edit component (we kunnen het overal importeren, maar aangezien deze stijlen voor de editor zijn, is het logischer om het component hier te importeren):
import "./editor.scss";
Als we nu rennen npm run build, worden de stijlen in beide contexten op het blok toegepast:
Aan de slag met WordPress Block DevelopmentAan de slag met WordPress Block Development
Verwijzen naar stijlen in block.json
We hebben de stijlbestanden geïmporteerd in de edit.js en index.js, maar onthoud dat de compilatiestap twee CSS-bestanden voor ons genereert in de build directory: index.css en style-index.css respectievelijk. We moeten naar deze gegenereerde bestanden verwijzen in de blokmetadata.
Laten we een paar uitspraken toevoegen aan de block.json metagegevens:
lopen npm run build nogmaals, installeer en activeer de plug-in op uw WordPress-site en u bent klaar om hem te gebruiken!
Je kunt gebruiken npm run start om uw build in de horlogemodus uit te voeren, waarbij uw code automatisch wordt gecompileerd telkens wanneer u een wijziging in uw code aanbrengt en opslaat.
We krabben aan de oppervlakte
Werkelijke blokken maken gebruik van de zijbalk Instellingen van de Block Editor en andere functies die WordPress biedt om rijke gebruikerservaringen te creëren. Bovendien, het feit dat er in wezen twee versies van ons blok zijn - edit en save - u moet ook nadenken over hoe u uw code organiseert om duplicatie van code te voorkomen.
Maar hopelijk helpt dit om het algemene proces voor het maken van WordPress-blokken te ontrafelen. Dit is echt een nieuw tijdperk in de ontwikkeling van WordPress. Het is moeilijk om nieuwe manieren te leren om dingen te doen, maar ik kijk er naar uit om te zien hoe het zich ontwikkelt. Hulpmiddelen zoals @wordpress/create-block helpen, maar zelfs dan is het fijn om precies te weten wat het doet en waarom.
Gaan de dingen die we hier hebben besproken veranderen? Meest waarschijnlijke! Maar je hebt in ieder geval een basis om vanaf te werken, aangezien we WordPress-blokken blijven zien rijpen, inclusief best practices om ze te maken.
Referenties
Nogmaals, mijn doel hier is om een efficiënt pad uit te stippelen om in dit seizoen in blokontwikkeling te komen, waar dingen snel evolueren en WordPress-documentatie het een beetje moeilijk heeft om in te halen. Hier zijn enkele bronnen die ik heb gebruikt om dit samen te brengen:
