Lassen Sie uns anerkennen, dass die Entwicklung für WordPress im Moment seltsam ist. Unabhängig davon, ob Sie neu bei WordPress sind oder seit Äonen damit arbeiten, die Einführung von „Full-Site Editing“ (FSE)-Funktionen, einschließlich der Blockeditor (WordPress 5.0) und die Site-Editor (WordPress 5.9), haben die traditionelle Art und Weise, wie wir WordPress-Themes und Plugins erstellen, auf den Kopf gestellt.
Obwohl es fünf Jahre her ist, seit wir den Blockeditor zum ersten Mal getroffen haben, ist die Entwicklung dafür schwierig, weil die Dokumentation entweder fehlt oder veraltet ist. Das ist eher eine Aussage darüber, wie schnell sich FSE-Features entwickeln, irgendetwas Geoff beklagte sich kürzlich in einem Beitrag.
Typisches Beispiel: Im Jahr 2018, an Einführungsserie über den Einstieg in die Gutenberg-Entwicklung wurde direkt hier auf CSS-Tricks veröffentlicht. Die Zeiten haben sich seitdem geändert, und obwohl dieser Entwicklungsstil immer noch funktioniert, funktioniert er nicht empfohlen mehr (außerdem die create-guten-block Projekt, auf dem es basiert, wird ebenfalls nicht mehr gepflegt).
In diesem Artikel möchte ich Ihnen helfen, mit der WordPress-Blockentwicklung auf eine Weise zu beginnen, die der aktuellen Methodik folgt. Also, ja, die Dinge könnten sich sehr gut ändern, nachdem dies veröffentlicht wurde. Aber ich werde versuchen, mich auf eine Weise darauf zu konzentrieren, die hoffentlich das Wesentliche der Blockentwicklung erfasst, denn obwohl sich die Tools im Laufe der Zeit weiterentwickeln, werden die Kernideen wahrscheinlich dieselben bleiben.
Der Gutenberg-Editor: (1) Der Block-Inserter, (2) der Inhaltsbereich und (3) die Seitenleiste mit den Einstellungen Kredit: WordPress-Blockeditor-Handbuch
Was genau sind WordPress-Blöcke?
Beginnen wir damit, etwas Verwirrung darüber zu beseitigen, was wir unter Begriffen wie verstehen Blöcke. Die gesamte Entwicklung, die in diese Funktionen bis hin zu WordPress 5.0 einfloss, trug den Codenamen „Gutenberg” — wissen Sie, der Erfinder der Druckerpresse.
Seitdem wird „Gutenberg“ verwendet, um alles zu beschreiben, was mit Blöcken zu tun hat, einschließlich des Block-Editors und des Site-Editors, so dass es für manche Leute so verworren ist den Namen verachten. Um das Ganze abzurunden, gibt es eine Gutenberg-Plugin wo experimentelle Features auf eine mögliche Einbeziehung getestet werden. Und wenn Sie denken, dass die Bezeichnung all dieser „Full-Site Editing“ das Problem lösen würde, da gibt es auch bedenken.
Wenn wir uns also in diesem Artikel auf „Blöcke“ beziehen, meinen wir damit Komponenten zum Erstellen von Inhalten im WordPress-Blockeditor. Blöcke werden in eine Seite oder einen Beitrag eingefügt und stellen die Struktur für eine bestimmte Art von Inhalten bereit. WordPress wird mit einer Handvoll „Kern“-Blöcken für gängige Inhaltstypen wie Absatz, Liste, Bild, Video und Audio ausgeliefert. um ein paar zu nennen.
Abgesehen von diesen Kernblöcken können wir auch benutzerdefinierte Blöcke erstellen. Darum geht es bei der Entwicklung von WordPress-Blöcken (es gibt auch das Filtern von Kernblöcken, um ihre Funktionalität zu ändern, aber das werden Sie wahrscheinlich noch nicht brauchen).
Was Blöcke tun
Bevor wir uns mit der Erstellung von Blöcken befassen, müssen wir zunächst ein Gefühl dafür bekommen, wie Blöcke intern funktionieren. Das wird uns später definitiv eine Menge Frust ersparen.
Die Art und Weise, wie ich über einen Block nachdenke, ist eher abstrakt: Für mich ist ein Block eine Entität mit einigen Eigenschaften (Attribute genannt), die einen Inhalt darstellen. Ich weiß, das klingt ziemlich vage, aber bleib bei mir. Ein Block manifestiert sich grundsätzlich auf zwei Arten: als grafische Oberfläche im Blockeditor oder als Datenblock in der Datenbank.
Wenn Sie den WordPress-Blockeditor öffnen und einen Block einfügen, sagen wir einen Pullquote-Block, erhalten Sie eine schöne Oberfläche. Sie können in diese Schnittstelle klicken und den zitierten Text bearbeiten. Das Einstellungsfenster auf der rechten Seite der Benutzeroberfläche des Blockeditors bietet Optionen zum Anpassen des Textes und zum Festlegen des Aussehens des Blocks.
Wenn Sie mit der Erstellung Ihres ausgefallenen Pullquotes fertig sind und auf „Veröffentlichen“ klicken, wird der gesamte Beitrag in der Datenbank im gespeichert wp_posts Tisch. Das ist wegen Gutenberg nichts Neues. So haben die Dinge immer funktioniert – WordPress speichert Post-Inhalte in einer dafür vorgesehenen Tabelle in der Datenbank. Aber was neu ist, ist das eine Darstellung des Pullquote-Blocks ist Teil des Inhalts, der gespeichert wird post_content Bereich der wp_posts Tabelle.
Wie sieht diese Darstellung aus? Guck mal:
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
Sieht aus wie einfaches HTML, oder?! Dies ist im Fachjargon der „serialisierte“ Block. Beachten Sie die JSON-Daten im HTML-Kommentar, "textAlign": "right". Das ist ein Attribut — eine dem Block zugeordnete Eigenschaft.
Angenommen, Sie schließen den Blockeditor und öffnen ihn einige Zeit später erneut. Der Inhalt aus dem relevanten post_content Feld wird vom Blockeditor abgerufen. Der Editor analysiert dann den abgerufenen Inhalt und wo immer er darauf trifft:
...
…es sagt sich laut:
OK, das scheint mir ein Pullquote-Block zu sein. Hmm ... es hat auch ein Attribut ... Ich habe eine JavaScript-Datei, die mir sagt, wie ich die grafische Oberfläche für einen Pullquote-Block im Editor aus seinen Attributen konstruieren kann. Ich sollte das jetzt tun, um diesen Block in seiner ganzen Pracht zu rendern.
Als Blockentwickler besteht Ihre Aufgabe darin:
Teilen Sie WordPress mit, dass Sie einen bestimmten Blocktyp mit so und so Details registrieren möchten.
Stellen Sie dem Blockeditor die JavaScript-Datei bereit, die ihm hilft, den Block im Editor zu rendern und ihn gleichzeitig zu „serialisieren“, um ihn in der Datenbank zu speichern.
Stellen Sie alle zusätzlichen Ressourcen bereit, die der Block für seine ordnungsgemäße Funktionalität benötigt, z. B. Stile und Schriftarten.
Zu beachten ist, dass diese gesamte Konvertierung von serialisierten Daten in die grafische Oberfläche – und umgekehrt – nur im Blockeditor stattfindet. Auf dem Frontend werden die Inhalte genau so angezeigt, wie sie hinterlegt sind. Daher sind Blöcke in gewisser Weise eine ausgefallene Art, Daten in die Datenbank zu stellen.
Hoffentlich gibt Ihnen dies etwas Klarheit darüber, wie ein Block funktioniert.
Erste Schritte mit der Entwicklung von WordPress-Blöcken
Blöcke sind nur Plugins
Blöcke sind nur Plugins. Nun, technisch gesehen Sie kann Setzen Sie Blöcke in Themen und Sie kann Fügen Sie mehrere Blöcke in ein Plugin ein. Aber in den meisten Fällen, wenn Sie einen Block erstellen möchten, erstellen Sie ein Plugin. Wenn Sie also jemals ein WordPress-Plugin erstellt haben, sind Sie bereits auf halbem Weg, einen WordPress-Block zu erstellen.
Aber nehmen wir für einen Moment an, dass Sie noch nie ein WordPress-Plugin eingerichtet haben, geschweige denn einen Block. Wo fängst du überhaupt an?
Block einrichten
Wir haben behandelt, was Blöcke sind. Fangen wir an, Dinge einzurichten, um einen zu machen.
Stellen Sie sicher, dass Node installiert ist
Dadurch erhalten Sie Zugriff auf npm und npx Befehle, wo npm installiert die Abhängigkeiten Ihres Blocks und hilft beim Kompilieren, während npx führt Befehle auf Paketen aus, ohne sie zu installieren. Wenn Sie macOS verwenden, haben Sie Node wahrscheinlich bereits und können es verwenden nvm Versionen zu aktualisieren. Wenn Sie Windows verwenden, müssen Sie dies tun Node herunterladen und installieren.
Erstellen Sie einen Projektordner
Jetzt könnten Sie auf andere Tutorials stoßen, die direkt in die Befehlszeile springen und Sie anweisen, ein Paket mit dem Namen zu installieren @wordpress/create-block. Dieses Paket ist großartig, weil es einen vollständig gestalteten Projektordner mit allen Abhängigkeiten und Tools ausspuckt, die Sie benötigen, um mit der Entwicklung zu beginnen.
Ich persönlich gehe diesen Weg, wenn ich meine eigenen Blöcke aufstelle, aber verzeihen Sie mir einen Moment, weil ich die eigensinnigen Dinge, die es einführt, durchschneiden und mich nur auf die erforderlichen Teile konzentrieren möchte, um die grundlegende Entwicklungsumgebung zu verstehen.
Dies sind die Dateien, die ich speziell nennen möchte:
readme.txt: Dies ist so etwas wie die Vorderseite des Plugin-Verzeichnisses, das normalerweise verwendet wird, um das Plugin zu beschreiben und zusätzliche Details zur Verwendung und Installation bereitzustellen. Wenn Sie Ihren Block an die senden WordPress Plugin Verzeichnis installieren, hilft diese Datei dabei, die Plugin-Seite zu füllen. Wenn Sie vorhaben, ein GitHub-Repo für Ihr Block-Plugin zu erstellen, sollten Sie auch ein README.md Datei mit denselben Informationen, damit sie dort gut angezeigt wird.
package.json: Dies definiert die Node-Pakete, die für die Entwicklung erforderlich sind. Wir werden es aufbrechen, wenn wir zur Installation kommen. In der klassischen WordPress-Plugin-Entwicklung sind Sie es vielleicht gewohnt, mit Composer und a zu arbeiten composer.json Datei stattdessen. Das ist das Äquivalent dazu.
plugin.php: Dies ist die Haupt-Plugin-Datei und, ja, es ist klassisches PHP! Wir werden unseren Plugin-Header und unsere Metadaten hier einfügen und sie verwenden, um das Plugin zu registrieren.
Zusätzlich zu diesen Dateien gibt es auch die src Verzeichnis, das den Quellcode unseres Blocks enthalten soll.
Mit diesen Dateien und der src Verzeichnis ist alles, was Sie brauchen, um loszulegen. Außerhalb dieser Gruppe, beachten Sie das wir benötigen technisch gesehen nur eine Datei (plugin.php), um das Plugin zu erstellen. Der Rest liefert entweder Informationen oder dient der Verwaltung der Entwicklungsumgebung.
Die vorgenannte @wordpress/create-block package erstellt diese Dateien (und mehr) für uns. Sie können es sich eher als Automatisierungstool denn als Notwendigkeit vorstellen. Unabhängig davon erleichtert es die Arbeit, sodass Sie sich die Freiheit nehmen können, einen Block damit zu bauen, indem Sie Folgendes ausführen:
npx @wordpress/create-block
Installieren Sie Blockabhängigkeiten
Angenommen, Sie haben die drei im vorherigen Abschnitt erwähnten Dateien bereit, ist es an der Zeit, die Abhängigkeiten zu installieren. Zuerst müssen wir die Abhängigkeiten angeben, die wir benötigen. Wir tun das, indem wir die bearbeiten package.json. Während der Verwendung der @wordpress/create-block wird Folgendes für uns generiert (Kommentare hinzugefügt; JSON unterstützt keine Kommentare, also entfernen Sie die Kommentare, wenn Sie den Code kopieren):
{
// 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"
}
}
Das @wordpress/scripts package ist hier die Hauptabhängigkeit. Wie Sie sehen können, ist es ein devDependency was bedeutet, dass es bei der Entwicklung hilft. Wie? Es entlarvt die wp-scripts Binärdatei, mit der wir unseren Code kompilieren können, aus der src Verzeichnis zum build Verzeichnis unter anderem.
Es gibt eine Reihe anderer Pakete, die WordPress für verschiedene Zwecke verwaltet. Zum Beispiel die @wordpress/components Paket bietet mehrere vorgefertigte UI Komponenten für den WordPress-Blockeditor, der zum Erstellen konsistenter Benutzererfahrungen für Ihren Block verwendet werden kann, der den Designstandards von WordPress entspricht.
Das tust du eigentlich nicht technische um diese Pakete zu installieren, auch wenn Sie sie verwenden möchten. Das liegt daran, dass diese @wordpress Abhängigkeiten werden nicht mit Ihrem Blockcode gebündelt. Stattdessen irgendwelche import Anweisungen, die auf Code aus Dienstprogrammpaketen verweisen – wie @wordpress/components — werden verwendet, um während der Kompilierung eine „Assets“-Datei zu erstellen. Darüber hinaus werden diese Importanweisungen in Anweisungen umgewandelt, die die Importe Eigenschaften eines globalen Objekts zuordnen. Zum Beispiel, import { __ } from "@wordpress/i18n" wird in eine verkleinerte Version von konvertiert const __ = window.wp.i18n.__. (window.wp.i18n ein Objekt zu sein, das garantiert im globalen Geltungsbereich verfügbar ist, sobald das entsprechende i18n Paketdatei wird in die Warteschlange eingereiht).
Während der Blockregistrierung in der Plugin-Datei wird die Datei „assets“ implizit verwendet, um WordPress die Paketabhängigkeiten für den Block mitzuteilen. Diese Abhängigkeiten werden automatisch in die Warteschlange eingereiht. All dies wird hinter den Kulissen erledigt, vorausgesetzt, Sie verwenden die scripts Paket. Davon abgesehen können Sie sich weiterhin dafür entscheiden, Abhängigkeiten für die Codevervollständigung und Parameterinformationen in Ihrem lokal zu installieren package.json Datei:
Nun package.json eingerichtet ist, sollten wir in der Lage sein, all diese Abhängigkeiten zu installieren, indem wir in der Befehlszeile zum Projektordner navigieren und ausführen npm install.
Erste Schritte mit der Entwicklung von WordPress-Blöcken
Fügen Sie den Plugin-Header hinzu
Wenn Sie aus der klassischen WordPress-Plugin-Entwicklung kommen, dann wissen Sie wahrscheinlich, dass alle Plugins einen Informationsblock in der Haupt-Plugin-Datei haben, der WordPress dabei hilft, das Plugin zu erkennen und Informationen darüber auf dem Plugins-Bildschirm des WordPress-Administrators anzuzeigen.
Hier ist, was @wordpress/create-block generiert für mich in für ein Plugin mit dem kreativen Namen „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
*/
Das ist in der Haupt-Plugin-Datei, die Sie nennen können, wie Sie möchten. Man könnte es so etwas generisches nennen index.php or plugin.phpdem „Vermischten Geschmack“. Seine create-block Das Paket nennt es automatisch das, was Sie bei der Installation als Projektnamen angeben. Da ich dieses Beispiel „Block Example“ genannt habe, gab uns das Paket a block-example.php Datei mit all diesen Sachen.
Sie werden einige Details ändern wollen, wie sich selbst zum Autor zu machen und so weiter. Und das alles ist nicht nötig. Wenn ich das von Grund auf neu rollen würde, könnte es ungefähr so aussehen:
<?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
*/
Wir haben uns bereits die erforderlichen Dateien für unseren Block angesehen. Aber wenn Sie verwenden @wordpress/create-block, sehen Sie eine Reihe anderer Dateien im Projektordner.
build/: Dieser Ordner erhielt die zusammengestellten Assets bei der Verarbeitung der Dateien für die Verwendung in der Produktion.
node_modules: Dies enthält alle Entwicklungsabhängigkeiten, die wir beim Ausführen installiert haben npm install.
src/: Dieser Ordner enthält den Quellcode des Plugins, der kompiliert und an die gesendet wird build Verzeichnis. Wir werden uns jede der Dateien hier gleich ansehen.
.editorconfig: Dies enthält Konfigurationen, um Ihren Code-Editor für Code-Konsistenz anzupassen.
.gitignore: Dies ist eine Standard-Repo-Datei, die lokale Dateien identifiziert, die von der Verfolgung der Versionskontrolle ausgeschlossen werden sollten. Dein node_modules gehören hier unbedingt dazu.
package-lock.json: Dies ist eine automatisch generierte Datei, die zum Nachverfolgen von Updates für die erforderlichen Pakete enthält, mit denen wir installiert haben npm install.
Metadaten blockieren
Ich möchte in die graben src Verzeichnis mit Ihnen, konzentriert sich aber zunächst auf nur eine Datei darin: block.json. Wenn du benutzt hast create-block , es ist bereits für Sie da; Wenn nicht, machen Sie weiter und erstellen Sie es. WordPress bemüht sich sehr, dies zur standardmäßigen, kanonischen Methode zum Registrieren eines Blocks zu machen, indem es Metadaten bereitstellt, die WordPress-Kontext bereitstellen, um den Block sowohl zu erkennen als auch im Block-Editor zu rendern.
Hier ist, was @wordpress/create-block für mich generiert:
Es gibt tatsächlich eine Haufen verschiedener Informationen wir können hier einschließen, aber alles, was tatsächlich erforderlich ist, ist name und title. Eine Super-Minimal-Version könnte so aussehen:
$schema definiert die Schemaformatierung, die zum Validieren des Inhalts in der Datei verwendet wird. Es klingt wie eine erforderliche Sache, ist aber völlig optional, da es unterstützenden Code-Editoren ermöglicht, die Syntax zu validieren und andere zusätzliche Angebote wie QuickInfo-Hinweise und automatische Vervollständigung bereitzustellen.
apiVersion bezieht sich auf welche Version der API blockieren das Plugin verwendet. Heute ist Version 2 die neueste.
name ist eine erforderliche eindeutige Zeichenfolge, die hilft, das Plugin zu identifizieren. Beachten Sie, dass ich dem vorangestellt habe css-tricks/ die ich als Namensraum verwende, um Konflikte mit anderen Plugins zu vermeiden, die möglicherweise denselben Namen haben. Sie können stattdessen etwas wie Ihre Initialen verwenden (z as/block-example).
title ist das andere erforderliche Feld und legt den Namen fest, der überall dort verwendet wird, wo das Plugin angezeigt wird.
category gruppiert den Block mit anderen Blöcken und zeigt sie zusammen im Blockeditor an. Derzeit vorhandene Kategorien umfassen text, media, design, widgets, theme und embed, und Sie können sogar erstellen benutzerdefinierte Kategorien.
icon lässt Sie etwas aus den auswählen Dashicons-Bibliothek um Ihren Block im Blockeditor visuell darzustellen. Ich benutze die format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote), da wir in diesem Beispiel unsere eigene Art Pullquote erstellen. Es ist schön, dass wir vorhandene Symbole nutzen können, anstatt unsere eigenen erstellen zu müssen, obwohl dies sicherlich möglich ist.
editorScript ist, wo die Haupt-JavaScript-Datei, index.js, lebt.
Registrieren Sie den Block
Eine letzte Sache, bevor wir zum eigentlichen Code kommen, und das ist die Registrierung des Plugins. Wir haben einfach all diese Metadaten eingerichtet und brauchen eine Möglichkeit für WordPress, sie zu nutzen. Auf diese Weise weiß WordPress, wo sich alle Plugin-Assets befinden, damit sie zur Verwendung im Block-Editor in die Warteschlange gestellt werden können.
Das Registrieren des Blocks ist ein zweifacher Prozess. Wir müssen es sowohl in PHP als auch in JavaScript registrieren. Öffnen Sie für die PHP-Seite die Haupt-Plugin-Datei (block-example.php in diesem Fall) und fügen Sie Folgendes direkt nach dem Plugin-Header hinzu:
Dies ist, was die create-block Dienstprogramm für mich generiert, deshalb heißt die Funktion so, wie sie ist. Wir können einen anderen Namen verwenden. Der Schlüssel liegt wiederum darin, Konflikte mit anderen Plugins zu vermeiden, daher ist es eine gute Idee, hier Ihren Namensraum zu verwenden, um ihn so eindeutig wie möglich zu machen:
Warum zeigen wir auf die build Verzeichnis, wenn die block.json mit allen Block-Metadaten ist drin src? Das liegt daran, dass unser Code noch kompiliert werden muss. Das scripts Paket verarbeitet den Code aus Dateien in der src Verzeichnis und legt die kompilierten Dateien, die in der Produktion verwendet werden, im build Verzeichnis, während auch Kopieren derblock.jsonDatei im Prozess.
Okay, gehen wir zur JavaScript-Seite der Registrierung des Blocks über. Aufmachen src/index.js und stellen Sie sicher, dass es so aussieht:
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,
});
Wir kommen ins React- und JSX-Land! Dies weist WordPress an:
Importieren Sie die registerBlockType Modul von der @wordpress/blocks Paket.
Metadaten importieren aus block.json.
Importieren Sie die Edit und Save Komponenten aus ihren entsprechenden Dateien. Wir werden später Code in diese Dateien einfügen.
Registrieren Sie den Block und verwenden Sie die Edit und Save Komponenten zum Rendern des Blocks und zum Speichern seines Inhalts in der Datenbank.
Was ist mit dem edit und save Funktionen? Eine der Nuancen der WordPress-Blockentwicklung ist die Unterscheidung des „Backends“ vom „Frontend“, und diese Funktionen werden verwendet, um den Inhalt des Blocks in diesen Kontexten zu rendern, wo edit verarbeitet Back-End-Rendering und save schreibt den Inhalt aus dem Blockeditor in die Datenbank, um den Inhalt auf dem Front-End der Website wiederzugeben.
Ein kurzer Test
Wir können schnell arbeiten, um zu sehen, wie unser Block im Blockeditor funktioniert und auf dem Frontend gerendert wird. Öffnen wir es index.js wieder und verwenden Sie die edit und save Funktionen, um einige grundlegende Inhalte zurückzugeben, die veranschaulichen, wie sie funktionieren:
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"
);
}
});
Dies ist im Grunde eine abgespeckte Version des gleichen Codes, den wir zuvor hatten, nur dass wir direkt auf die Metadaten darin verweisen block.json um den Blocknamen zu holen, und weggelassen Edit und Save Komponenten, da wir die Funktionen direkt von hier aus ausführen.
Wir können dies durch Ausführen kompilieren npm run build in der Kommandozeile. Danach haben wir Zugriff auf einen Block namens „Block Example“ im Blockeditor:
Wenn wir den Block in den Inhaltsbereich ziehen, erhalten wir die Nachricht, die wir von der zurückgeben edit Funktion:
Erste Schritte mit der Entwicklung von WordPress-Blöcken
Wenn wir den Beitrag speichern und veröffentlichen, sollten wir die Nachricht erhalten, die wir von der zurücksenden save Funktion bei Anzeige am Frontend:
Erste Schritte mit der Entwicklung von WordPress-Blöcken
Erstellen eines Blocks
Scheint alles angeschlossen zu sein! Wir können auf das zurückgreifen, was wir hatten index.js vor dem Test jetzt, wo wir bestätigt haben, dass alles funktioniert:
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,
});
Beachten Sie, dass die edit und save Funktionen sind an zwei vorhandene Dateien in der gebunden src Verzeichnis das @wordpress/create-block für uns generiert und enthält alle zusätzlichen Importe, die wir in jeder Datei benötigen. Noch wichtiger ist jedoch, dass diese Dateien die Edit und Save Komponenten, die das Markup des Blocks enthalten.
Back-End-Markup (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")}
);
}
Sehen Sie, was wir dort gemacht haben? Wir importieren Requisiten aus der @wordpress/block-editor Paket, mit dem wir Klassen generieren können, die wir später für das Styling verwenden können. Wir importieren auch die __ Internationalisierungsfunktion, für den Umgang mit Übersetzungen.
Erste Schritte mit der Entwicklung von WordPress-Blöcken
Front-End-Markup (src/save.js)
Dies schafft ein Save Komponente und wir werden so ziemlich dasselbe verwenden wie src/edit.js mit etwas anderem Text:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Auch hier erhalten wir eine schöne Klasse, die wir in unserem CSS verwenden können:
Erste Schritte mit der Entwicklung von WordPress-Blöcken
Styling-Blöcke
Wir haben gerade behandelt, wie Block-Requisiten zum Erstellen von Klassen verwendet werden. Sie lesen diesen Artikel auf einer Website, die sich ausschließlich mit CSS befasst, daher habe ich das Gefühl, dass mir etwas entgehen würde, wenn wir uns nicht speziell mit dem Schreiben von Blockstilen befassen würden.
Unterscheiden von Front- und Back-End-Stilen
Wenn Sie sich das ansehen block.json der src Verzeichnis finden Sie zwei Felder, die sich auf Stile beziehen:
editorStyle stellt den Pfad zu den Stilen bereit, die auf das Backend angewendet werden.
style ist der Pfad für freigegebene Stile, die sowohl auf das Front- als auch auf das Backend angewendet werden.
Daran erinnern, dass die @wordpress/scripts Paket kopiert die block.json Datei, wenn es den Code in der verarbeitet /src Verzeichnis und platziert zusammengestellte Assets im /build Verzeichnis. Es ist der build/block.json Datei, die zum Registrieren des Blocks verwendet wird. Das bedeutet jeden Pfad, den wir bereitstellen src/block.json sollte relativ zu geschrieben werden build/block.json.
Mit Sass
Wir könnten ein paar CSS-Dateien in die build Verzeichnis, verweisen Sie auf die Pfade in src/block.json, führen Sie den Build aus und nennen Sie es einen Tag. Aber das nutzt nicht die volle Kraft des @wordpress/scripts Kompilierungsprozess, der in der Lage ist, Sass in CSS zu kompilieren. Stattdessen platzieren wir unsere Style-Dateien in der src Verzeichnis und importieren Sie sie in JavaScript.
Dabei müssen wir darauf achten, wie @wordpress/scripts verarbeitet Stile:
Eine Datei mit dem Namen style.css or style.scss or style.sass, importiert in den JavaScript-Code, kompiliert wird style-index.css.
Alle anderen Stildateien werden kompiliert und gebündelt index.css.
Das @wordpress/scripts Paket verwendet Webpack zum Bündeln u @wordpress/scripts verwendet das PostCSS-Plugin zum Arbeiten für Verarbeitungsstile. PostCSS kann mit zusätzlichen Plugins erweitert werden. Das scripts Das Paket verwendet diejenigen für Sass, SCSS und Autoprefixer, die alle ohne Installation zusätzlicher Pakete verwendet werden können.
In der Tat, wenn Sie Ihren anfänglichen Block mit hochdrehen @wordpress/create-block, erhalten Sie einen guten Vorsprung mit SCSS-Dateien, mit denen Sie sofort durchstarten können:
editor.scss enthält alle Stile, die auf den Back-End-Editor angewendet werden.
style.scss enthält alle Stile, die sowohl vom Front- als auch vom Backend gemeinsam genutzt werden.
Sehen wir uns diesen Ansatz nun in Aktion an, indem wir ein kleines Sass schreiben, das wir in das CSS für unseren Block kompilieren. Obwohl die Beispiele nicht sehr frech sein werden, schreibe ich sie dennoch in die SCSS-Dateien, um den Kompilierungsprozess zu demonstrieren.
Vorderreifen und Back-End-Stile
OK, beginnen wir mit Stilen, die sowohl auf das Front- als auch auf das Backend angewendet werden. Zuerst müssen wir erstellen src/style.scss (Es ist bereits vorhanden, wenn Sie verwenden @wordpress/create-block) und stellen Sie sicher, dass wir es importieren, was wir in tun können index.js:
import "./style.scss";
Erschließen Sie src/style.scss und legen Sie dort ein paar grundlegende Stile ab, indem Sie die Klasse verwenden, die für uns aus den Block-Requisiten generiert wurde:
Das war es fürs Erste! Wenn wir den Build ausführen, wird dies kompiliert build/style.css und wird sowohl vom Blockeditor als auch vom Frontend referenziert.
Back-End-Stile
Möglicherweise müssen Sie Stile schreiben, die für den Blockeditor spezifisch sind. Erstellen Sie dazu src/editor.scss (nochmal, @wordpress/create-block erledigt dies für Sie) und legen Sie dort einige Stile ab:
Importieren Sie es dann ein edit.js, das ist die Datei, die unsere enthält Edit Komponente (wir können sie überall importieren, aber da diese Stile für den Editor sind, ist es logischer, die Komponente hier zu importieren):
import "./editor.scss";
Jetzt, wenn wir laufen npm run build, werden die Stile in beiden Kontexten auf den Block angewendet:
Erste Schritte mit der Entwicklung von WordPress-BlöckenErste Schritte mit der Entwicklung von WordPress-Blöcken
Referenzstile in block.json
Wir haben die Styling-Dateien in die importiert edit.js und index.js, aber denken Sie daran, dass der Kompilierungsschritt zwei CSS-Dateien für uns in der erzeugt build Verzeichnis: index.css und style-index.css beziehungsweise. Wir müssen diese generierten Dateien in den Blockmetadaten referenzieren.
Lassen Sie uns dem ein paar Aussagen hinzufügen block.json Metadaten:
Führen Sie npm run build Installieren und aktivieren Sie das Plugin noch einmal auf Ihrer WordPress-Site, und Sie können es verwenden!
Sie können verwenden npm run start um Ihren Build im Überwachungsmodus auszuführen und Ihren Code jedes Mal automatisch zu kompilieren, wenn Sie eine Änderung an Ihrem Code vornehmen und speichern.
Wir kratzen an der Oberfläche
Tatsächliche Blöcke nutzen die Seitenleiste „Einstellungen“ des Block-Editors und andere Funktionen, die WordPress bietet, um umfassende Benutzererfahrungen zu schaffen. Außerdem die Tatsache, dass es im Wesentlichen zwei Versionen unseres Blocks gibt – edit und save – Sie müssen auch darüber nachdenken, wie Sie Ihren Code organisieren, um Codeduplizierung zu vermeiden.
Aber hoffentlich hilft dies dabei, den allgemeinen Prozess zum Erstellen von WordPress-Blöcken zu entmystifizieren. Dies ist wirklich eine neue Ära in der WordPress-Entwicklung. Es ist schwer, neue Wege zu lernen, Dinge zu tun, aber ich freue mich darauf, zu sehen, wie es sich entwickelt. Werkzeuge wie @wordpress/create-block helfen, aber selbst dann ist es schön, genau zu wissen, was es tut und warum.
Werden sich die Dinge, die wir hier behandelt haben, ändern? Höchstwahrscheinlich! Aber zumindest haben Sie eine Ausgangsbasis, von der aus Sie arbeiten können, während wir die Weiterentwicklung von WordPress-Blöcken beobachten, einschließlich Best Practices für deren Erstellung.
Bibliographie
Auch hier ist es mein Ziel, einen effizienten Weg für den Einstieg in die Blockentwicklung in dieser Saison aufzuzeigen, in der sich die Dinge schnell entwickeln und die WordPress-Dokumentation es etwas schwer hat, aufzuholen. Hier sind einige Ressourcen, die ich verwendet habe, um dies zusammenzuführen:
