Verwaltung von WordPress-Metadaten in Gutenberg mit einem Seitenleisten-Plugin

WordPress hat seinen mit Spannung erwarteten Wechsel zum Beitragseditor vorgenommen, der den Spitznamen Gutenberg trägt und auch als Block-Editor bezeichnet wird. Er verwandelt einen WordPress-Beitrag in eine Sammlung von Blöcken, die Sie im Layout hinzufügen, bearbeiten, entfernen und neu anordnen können. Vor der offiziellen Veröffentlichung war Gutenberg als Plugin verfügbar und in dieser Zeit war ich daran interessiert zu lernen, wie man benutzerdefinierte Blöcke für den Editor erstellt. Ich konnte viel über Gutenberg lernen, dass ich mich entschied, einen Kurs zusammenzustellen, der fast alles behandelt, was Sie wissen müssen, um Blöcke für Gutenberg zu entwickeln.

In diesem Artikel werden wir Metoboxen und Metafelder in WordPress besprechen. Insbesondere werden wir behandeln, wie die alten PHP-Metaboxen in Gutenberg ersetzt und die Seitenleiste von Gutenberg erweitert werden, um eine React-Komponente hinzuzufügen, die zur Manipulation der Metadaten mithilfe der globalen JavaScript-Redux-ähnlichen Stores verwendet wird. Beachten Sie, dass Metadaten in Gutenberg auch mithilfe von Blöcken manipuliert werden können. Beide Wege werden in meinem Kurs besprochen. In diesem Artikel werde ich mich jedoch auf die Verwaltung von Metadaten in der Seitenleiste konzentrieren, da ich glaube, dass diese Methode häufiger verwendet wird.

Dieser Artikel setzt einige Kenntnisse in ReactJS und Redux voraus. Gutenberg stützt sich stark auf diese Technologien, um die Benutzeroberfläche darzustellen und den Zustand zu verwalten. Sie können auch den CSS-Tricks-Leitfaden zum Erlernen von Gutenberg für eine Einführung in einige der hier behandelten Konzepte lesen.

Gutenberg ist eine React-Anwendung

Im Kern ist Gutenberg eine ReactJS-Anwendung. Alles, was Sie im Editor sehen, wird mit einer React-Komponente gerendert. Der Beitragstitel, der Inhaltsbereich, der die Blöcke enthält, die obere Symbolleiste und die rechte Seitenleiste sind alles React-Komponenten. Daten oder Anwendungszustände in dieser React-Anwendung werden in zentralisierten JavaScript-Objekten oder „Stores“ gespeichert. Diese Stores werden vom Datenmodul von WordPress verwaltet. Dieses Modul teilt viele Kernprinzipien mit Redux. Konzepte wie Stores, Reducer, Actions, Action Creators usw. existieren daher auch in diesem Modul. Ich werde diese Stores manchmal als „Redux-ähnliche“ Stores bezeichnen.

Diese Stores speichern nicht nur Daten über den aktuellen Beitrag, wie z. B. den Beitragstext (die Blöcke), den Beitragstitel und die ausgewählten Kategorien, sondern auch globale Informationen über eine WordPress-Website, wie z. B. alle Kategorien, Tags, Beiträge, Anhänge usw. Zusätzlich werden UI-Zustandsinformationen wie „Ist die Seitenleiste geöffnet oder geschlossen?“ ebenfalls in diesen globalen Stores gespeichert. Eine der Aufgaben des „Datenmoduls“ ist es, Daten aus diesen Stores abzurufen und Daten in den Stores zu ändern. Da diese Stores global sind und von mehreren React-Komponenten verwendet werden können, werden Änderungen an Daten in einem beliebigen Store in jedem Teil der Gutenberg-Oberfläche (einschließlich Blöcken) reflektiert, der diese Daten verwendet.

Sobald ein Beitrag gespeichert wird, wird die WordPress REST API verwendet, um den Beitrag mit den in diesen globalen Stores gespeicherten Daten zu aktualisieren. So werden der Beitragstitel, der Inhalt, die Kategorien usw., die in diesen globalen Stores gespeichert sind, als Payload an den WP REST API-Endpunkt gesendet, der den Beitrag aktualisiert. Wenn wir also in der Lage sind, Daten in diesen Stores zu manipulieren, werden die von uns manipulierten Daten, sobald der Benutzer auf Speichern klickt, von der API in der Datenbank gespeichert, ohne dass wir etwas tun müssen.

Eine der Dinge, die in Gutenberg nicht von diesen globalen Stores verwaltet werden, sind Metadaten. Wenn Sie einige Metafelder haben, die Sie im „klassischen“ Editor vor Gutenberg mit einer Metabox verwaltet haben, werden diese standardmäßig nicht mit den globalen Redux-ähnlichen Stores gespeichert und manipuliert. Wir können uns jedoch dafür entscheiden, Metadaten mithilfe von JavaScript und den Redux-ähnlichen Stores zu verwalten. Obwohl diese alten PHP-Metaboxen weiterhin in Gutenberg angezeigt werden, empfiehlt WordPress, diese PHP-Metaboxen durch einen anderen Ansatz zu ersetzen, der die globalen Stores und React-Komponenten verwendet. Dies gewährleistet eine einheitlichere und konsistentere Erfahrung. Sie können mehr über Probleme erfahren, die bei der Verwendung von PHP-Metaboxen in Gutenberg auftreten können.

Bevor wir beginnen, werfen wir einen Blick auf die Redux-ähnlichen Stores in Gutenberg und wie man sie benutzt.

Abrufen und Ändern von Daten in Gutenbergs Redux-ähnlichen Stores

Wir wissen jetzt, dass die Gutenberg-Seite mithilfe dieser Redux-ähnlichen Stores verwaltet wird. Wir haben einige Standard-„Core“-Stores, die von WordPress definiert werden. Zusätzlich können wir auch eigene Stores definieren, wenn wir Daten haben, die wir zwischen mehreren Blöcken oder sogar zwischen Blöcken und anderen UI-Elementen auf der Gutenberg-Seite, wie z. B. der Seitenleiste, austauschen möchten. Das Erstellen eigener Stores wird ebenfalls in meinem Kurs besprochen und Sie können dies in den offiziellen Dokumenten nachlesen. In diesem Artikel konzentrieren wir uns jedoch darauf, wie die vorhandenen Stores verwendet werden. Die Verwendung der vorhandenen Stores ermöglicht es uns, Metadaten zu manipulieren; daher müssen wir keine benutzerdefinierten Stores erstellen.

Um auf diese Stores zugreifen zu können, stellen Sie sicher, dass Sie die neueste WordPress-Version mit aktiviertem Gutenberg haben und bearbeiten Sie einen beliebigen Beitrag oder eine beliebige Seite. Öffnen Sie dann die Browserkonsole und geben Sie die folgende Anweisung ein.

wp.data.select('core/editor').getBlocks()

Sie sollten etwas Ähnliches wie hier sehen.

Lassen Sie uns das aufschlüsseln. Zuerst greifen wir auf das wp.data-Modul zu, das (wie besprochen) für die Verwaltung der Redux-ähnlichen Stores verantwortlich ist. Dieses Modul ist in der globalen wp-Variable verfügbar, wenn Sie Gutenberg in Ihrer WordPress-Installation haben. Dann rufen wir innerhalb dieses Moduls eine Funktion namens select auf. Diese Funktion empfängt einen Store-Namen als Argument und gibt alle Selektoren für diesen Store zurück. Ein Selektor ist ein Begriff, der vom Datenmodul verwendet wird und einfach eine Funktion bedeutet, die Daten aus dem Store abruft. In unserem Beispiel haben wir auf den core/editor-Store zugegriffen, und dieser gibt eine Reihe von Funktionen zurück, die zum Abrufen von Daten aus diesem Store verwendet werden können. Eine dieser Funktionen ist getBlocks(), die wir oben aufgerufen haben. Diese Funktion gibt ein Array von Objekten zurück, wobei jedes Objekt einen Block in Ihrem aktuellen Beitrag darstellt. Je nachdem, wie viele Blöcke Sie in Ihrem Beitrag haben, ändert sich dieses Array.

Wie wir gesehen haben, haben wir auf einen Store namens core/editor zugegriffen. Dieser Store enthält Informationen über den aktuell bearbeiteten Beitrag. Wir haben auch gesehen, wie man die Blöcke im aktuellen Beitrag abruft, aber wir können auch viele andere Dinge abrufen. Wir können den Titel des aktuellen Beitrags, die ID des aktuellen Beitrags, den Beitragstyp des aktuellen Beitrags und praktisch alles andere abrufen, was wir benötigen.

Aber im obigen Beispiel konnten wir nur Daten abrufen. Was ist, wenn wir Daten *ändern* wollen? Betrachten wir einen weiteren Selektor im Store 'core/editor'. Führen wir diesen Selektor in unserer Browserkonsole aus.

wp.data.select('core/editor').getEditedPostAttribute('title')

Dies sollte den Titel des gerade bearbeiteten Beitrags zurückgeben.

Großartig! Was ist, wenn wir den Titel über das Datenmodul ändern wollen? Anstatt select() aufzurufen, können wir dispatch() aufrufen, das ebenfalls einen Store-Namen empfängt und einige Aktionen zurückgibt, die Sie auslösen können. Wenn Sie mit Redux vertraut sind, werden Begriffe wie „Actions“ und „dispatch“ Ihnen bekannt vorkommen. Wenn dies neu für Sie ist, müssen Sie nur wissen, dass das Auslösen einer bestimmten Aktion einfach bedeutet, Daten in einem Store zu ändern. In unserem Fall möchten wir den Beitragstitel im Store ändern, daher können wir diese Funktion aufrufen.

wp.data.dispatch('core/editor').editPost({title: 'My new title'})

Schauen Sie sich jetzt den Beitragstitel im Editor an – er wird entsprechend geändert!

So können wir beliebige Daten in der Gutenberg-Oberfläche manipulieren. Wir rufen die Daten mithilfe von Selektoren ab und ändern diese Daten mithilfe von Aktionen. Jede Änderung wird in jedem Teil der Benutzeroberfläche, der diese Daten verwendet, reflektiert.

Es gibt natürlich noch weitere Stores in Gutenberg, die Sie auf dieser Seite finden können. Werfen wir also einen kurzen Blick auf ein paar weitere Stores, bevor wir weitermachen.

Die Stores, die Sie am häufigsten verwenden werden, sind core/editor, den wir gerade betrachtet haben, und der core-Store. Im Gegensatz zu core/editor enthält der core-Store Informationen nicht nur über den gerade bearbeiteten Beitrag, sondern auch über die gesamte WordPress-Website im Allgemeinen. So können wir beispielsweise alle Autoren der Website abrufen mit

wp.data.select('core').getAuthors()

Wir können auch einige Beiträge von der Website abrufen, wie folgt.

wp.data.select('core').getEntityRecords('postType','post',{per_page: 5})

Stellen Sie sicher, dass Sie dies zweimal ausführen, wenn das erste Ergebnis null war. Einige Selektoren wie dieser senden zuerst einen API-Aufruf, um Ihren Beitrag abzurufen. Das bedeutet, dass der zurückgegebene Wert anfänglich null sein wird, bis die API-Anfrage erfüllt ist.

Betrachten wir noch einen Store: edit-post. Dieser Store ist für die UI-Informationen im eigentlichen Editor zuständig. Zum Beispiel können wir Selektoren haben, die prüfen, ob die Seitenleiste gerade geöffnet ist.

wp.data.select('core/edit-post').isEditorSidebarOpened()

Dies gibt true zurück, wenn die Seitenleiste geöffnet ist. Aber versuchen Sie, die Seitenleiste zu schließen, führen Sie diese Funktion erneut aus, und sie sollte false zurückgeben.

Wir können die Seitenleiste auch öffnen und schließen, indem wir Aktionen in diesem Store auslösen. Wenn die Seitenleiste geöffnet ist und Sie diese Aktion in der Browserkonsole ausführen, sollte die Seitenleiste geschlossen werden.

wp.data.dispatch('core/edit-post').closeGeneralSidebar()

Sie werden diesen Store wahrscheinlich nicht verwenden müssen, aber es ist gut zu wissen, dass dies das ist, was Gutenberg tut, wenn Sie auf das Seitenleistensymbol klicken, um es zu schließen.

Es gibt noch einige weitere Stores, die Sie sich ansehen sollten. Der core/notices-Store könnte zum Beispiel nützlich sein. Dieser kann Ihnen helfen, Fehler-, Warn- und Erfolgsmeldungen auf der Gutenberg-Seite anzuzeigen. Sie können auch alle anderen Stores hier einsehen.

Versuchen Sie, mit diesen Stores in Ihrem Browser herumzuspielen, bis Sie sich damit wohlfühlen. Danach können wir sehen, wie wir sie in echtem Code außerhalb des Browsers verwenden.

Einrichten eines WordPress-Plugins, um eine Gutenberg-Seitenleiste hinzuzufügen

Nachdem wir nun wissen, wie man die Redux-ähnlichen Stores in Gutenberg verwendet, ist der nächste Schritt, eine React-Seitenleistenkomponente im Editor hinzuzufügen. Diese React-Komponente wird mit dem core/editor-Store verbunden und enthält einige Eingaben, die beim Ändern einige Aktionen auslösen, die Metadaten manipulieren – ähnlich wie wir zuvor den Beitragstitel manipuliert haben. Dazu müssen wir jedoch ein WordPress-Plugin erstellen, das unseren Code enthält.

Sie können mitverfolgen, indem Sie das Repository für dieses Beispiel auf GitHub klonen oder herunterladen.

Erstellen wir einen neuen Ordner im Verzeichnis wp-content/plugins der WordPress-Installation. Ich nenne ihn gutenberg-sidebar. Erstellen wir in diesem Ordner den Einstiegspunkt für unser Plugin. Der Einstiegspunkt ist die PHP-Datei, die beim Aktivieren Ihres Plugins ausgeführt wird. Sie kann index.php oder plugin.php heißen. Wir verwenden für dieses Beispiel plugin.php und fügen oben einige Informationen über das Plugin hinzu sowie Code, der den direkten Zugriff verhindert.

<?php
/**
  * Plugin Name: gutenberg-sidebar
  * Plugin URI: https://alialaa.com/
  * Description: Sidebar for the block editor.
  * Author: Ali Alaa
  * Author URI: https://alialaa.com/
  */
if( ! defined( 'ABSPATH') ) {
    exit;
}

Sie sollten Ihr Plugin auf der Plugin-Seite im WordPress-Adminbereich finden. Klicken Sie auf „Aktivieren“, damit der Code ausgeführt wird.

Wie Sie sich vorstellen können, werden wir von nun an viel JavaScript und React schreiben. Um React-Komponenten einfach codieren zu können, müssen wir JSX verwenden. Und JSX ist kein gültiges JavaScript, das in Ihrem Browser ausgeführt werden kann; es muss in reines JavaScript konvertiert werden. Möglicherweise müssen wir auch ESNext-Funktionen und Import-Anweisungen zum Importieren und Exportieren von Modulen verwenden.

Und diese Funktionen funktionieren nicht in allen Browsern, daher ist es besser, unseren Code in altes ES5-JavaScript zu transformieren. Glücklicherweise gibt es viele Werkzeuge, die uns dabei helfen können. Ein bekanntes ist webpack. webpack ist jedoch ein eigenes großes Thema und sprengt den Rahmen dieses Artikels. Daher werden wir ein weiteres Werkzeug verwenden, das WordPress bereitstellt: @wordpress/scripts. Durch die Installation dieses Pakets erhalten wir eine empfohlene webpack-Konfiguration, ohne etwas selbst in webpack tun zu müssen. Persönlich empfehle ich Ihnen, webpack zu lernen und die Konfiguration selbst vorzunehmen. Dies hilft Ihnen, zu verstehen, was vor sich geht, und gibt Ihnen mehr Kontrolle. Sie finden viele Ressourcen online und es wird auch in meinem Kurs besprochen. Aber vorerst installieren wir das webpack-Konfigurationstool von WordPress.

Wechseln Sie im Terminal in Ihren Plugin-Ordner.

cd path/to/your/theme/folder

Als Nächstes müssen wir in diesem Ordner npm initialisieren, um @wordpress/scripts zu installieren. Dies kann durch Ausführen des folgenden Befehls erfolgen.

npm init

Dieser Befehl stellt Ihnen einige Fragen, wie z. B. den Paketnamen, die Version, die Lizenz usw. Sie können die Eingabetaste gedrückt halten und die Standardwerte übernehmen. Sie sollten eine package.json-Datei in Ihrem Ordner haben, und wir können mit der Installation von npm-Paketen beginnen. Installieren wir @wordpress/scripts, indem wir den folgenden Befehl ausführen.

npm install @wordpress/scripts --save-dev

Dieses Paket stellt eine CLI namens wp-scripts bereit, die Sie in Ihren npm-Skripten verwenden können. Es gibt verschiedene Befehle, die Sie ausführen können. Wir konzentrieren uns vorerst auf die Befehle build und start. Das <code>build</code>-Skript transformiert Ihre Dateien, damit sie minimiert und für die Produktion bereit sind. Der Einstiegspunkt Ihres Quellcodes ist in src/index.js konfiguriert und die transformierte Ausgabe wird in build/index.js sein. Ebenso transformiert das start-Skript Ihren Code in src/index.js nach build/index.js. Diesmal wird der Code jedoch nicht minimiert, um Zeit und Speicher zu sparen – der Befehl überwacht auch Änderungen in Ihren Dateien und baut Ihre Dateien jedes Mal neu, wenn etwas geändert wird. Der Befehl start eignet sich für die Entwicklung, während der Befehl build für die Produktion gedacht ist. Um diese Befehle zu verwenden, ersetzen wir den Schlüssel scripts in der Datei package.json, die wie folgt aussehen sollte, wenn Sie beim Initialisieren von npm die Standardoptionen verwendet haben.

Ändern Sie dies

"scripts": {
  "test": "echo "Error: no test specified" && exit 1"
},

...zu diesem:

"scripts": {
  "start": "wp-scripts start",
  "build": "wp-scripts build"
},

Jetzt können wir npm start und npm run build ausführen, um die Entwicklung zu starten bzw. Dateien zu erstellen.

Erstellen wir einen neuen Ordner im Stammverzeichnis des Plugins namens src und fügen Sie eine Datei index.js hinzu. Wir können sehen, ob die Dinge funktionieren, indem wir ein wenig JavaScript einfügen. Wir versuchen einen Alarm.

Führen Sie nun npm start im Terminal aus. Sie sollten den Ordner build finden, der mit der kompilierten index.js und auch Sourcemap-Dateien erstellt wurde. Darüber hinaus werden Sie feststellen, dass die Datei build/index.js nicht minimiert ist und webpack auf Änderungen wartet. Versuchen Sie, die Datei src/index.js zu ändern und erneut zu speichern. Die Datei build/index.js wird neu generiert.

Wenn Sie die Überwachung stoppen (Strg + C) im Terminal und npm run build ausführen, sollte die Datei build/index.js jetzt minimiert sein.

---

Nachdem wir nun unser JavaScript-Bundle haben, müssen wir diese Datei im Gutenberg-Editor registrieren. Dazu können wir den Hook enqueue_block_editor_assets verwenden, der sicherstellt, dass die Dateien nur auf der Gutenberg-Seite registriert werden und nicht auf anderen wp-admin-Seiten, wo sie nicht benötigt werden.

Wir können unsere Datei wie folgt in plugin.php registrieren.

// Note that it’s a best practice to prefix function names (e.g. myprefix)
function myprefix_enqueue_assets() {
  wp_enqueue_script(
    'myprefix-gutenberg-sidebar',
    plugins_url( 'build/index.js', __FILE__ )
  );
}
add_action( 'enqueue_block_editor_assets', 'myprefix_enqueue_assets' );

Besuchen Sie die Gutenberg-Seite. Wenn alles in Ordnung ist, sollten Sie einen Alarm erhalten, dank dem, was wir zuvor zu src/index.js hinzugefügt haben.

Fantastisch! Wir sind bereit, etwas JavaScript-Code zu schreiben, also legen wir los!

Importieren von WordPress JavaScript-Paketen

Um der bestehenden Gutenberg-Seitenleiste Inhalte hinzuzufügen oder eine neue leere Seitenleiste zu erstellen, müssen wir ein Gutenberg-JavaScript-Plugin registrieren – und dafür müssen wir einige Funktionen und Komponenten aus Paketen verwenden, die von WordPress bereitgestellt werden: wp-plugins, wp-edit-post und wp-i18n. Diese Pakete werden in der globalen Variablen wp im Browser als wp.plugins, wp.editPost und wp.i18n verfügbar sein.

Wir können die benötigten Funktionen in src/index.js importieren. Insbesondere sind dies die Funktionen: registerPlugin und PluginSidebar.

const { registerPlugin } = wp.plugins;
const { PluginSidebar } = wp.editPost;
const { __ } = wp.i18n;

Es ist erwähnenswert, dass wir sicherstellen müssen, dass wir diese Dateien als Abhängigkeiten haben, wenn wir unsere JavaScript-Datei registrieren, um sicherzustellen, dass unsere index.js-Datei nach den Paketen wp-plugins, wp-edit-posts und wp-i18n geladen wird. Fügen wir diese zu plugin.php hinzu.

function myprefix_enqueue_assets() {
  wp_enqueue_script(
    'myprefix-gutenberg-sidebar',
    plugins_url( 'build/index.js', __FILE__ ),
    array( 'wp-plugins', 'wp-edit-post', 'wp-i18n', 'wp-element' )
  );
}
add_action( 'enqueue_block_editor_assets', 'myprefix_enqueue_assets' );

Beachten Sie, dass ich wp-element als Abhängigkeit hinzugefügt habe. Das habe ich getan, weil wir einige React-Komponenten mit JSX schreiben werden. Typischerweise würden wir die gesamte React-Bibliothek importieren, wenn wir React-Komponenten erstellen. wp-element ist jedoch eine Abstraktionsschicht über React, sodass wir React nie direkt installieren oder importieren müssen. Stattdessen verwenden wir wp-element als globale Variable.

Diese Pakete sind auch als npm-Pakete verfügbar. Anstatt Funktionen aus der globalen wp-Variable zu importieren (die nur im Browser verfügbar ist, von der Ihr Code-Editor nichts weiß), können wir diese Pakete einfach mit npm installieren und sie in unserer Datei importieren. Diese WordPress-Pakete sind normalerweise mit @wordpress präfigiert.

Installieren wir die beiden benötigten Pakete.

npm install @wordpress/edit-post @wordpress/plugins @wordpress/i18n --save

Jetzt können wir unsere Pakete in index.js importieren.

import { registerPlugin } from "@wordpress/plugins";
import { PluginSidebar } from "@wordpress/edit-post";
import { __ } from "@wordpress/i18n";

Der Vorteil des Imports der Pakete auf diese Weise ist, dass Ihr Texteditor weiß, was @wordpress/edit-post und @wordpress/plugins sind und er Funktionen und Komponenten für Sie vervollständigen kann – im Gegensatz zum Importieren von wp.plugins und wp.editPost, die nur im Browser verfügbar sind, während der Texteditor keine Ahnung hat, was wp ist.

Sie denken vielleicht auch, dass der Import dieser Pakete in Ihr Bundle die Bundle-Größe erhöht, aber das ist kein Grund zur Sorge. Die webpack-Konfigurationsdatei, die mit @wordpress/scripts geliefert wird, ist so konfiguriert, dass diese @wordpress-Pakete nicht gebündelt werden und stattdessen auf die globale wp-Variable zurückgegriffen wird. Als Ergebnis wird das endgültige Bundle tatsächlich nicht die verschiedenen Pakete enthalten, sondern sie über die wp-Variable referenzieren.

Großartig! Ich werde mich in diesem Artikel darauf konzentrieren, Pakete über npm zu importieren, aber Sie können natürlich auch aus der globalen wp-Variable importieren, wenn Sie dies bevorzugen. Lassen Sie uns nun die Funktionen verwenden, die wir importiert haben!

Registrieren eines Gutenberg-Plugins

Um eine neue benutzerdefinierte Seitenleiste in Gutenberg hinzuzufügen, müssen wir zuerst ein Plugin registrieren – und das tut die von uns importierte Funktion registerPlugin. Als erstes Argument erhält registerPlugin einen eindeutigen Slug für dieses Plugin. Als zweites Argument kann ein Array von Optionen übergeben werden. Unter diesen Optionen können wir einen Icon-Namen (aus der Dashicons-Bibliothek) und eine Render-Funktion haben. Diese Render-Funktion kann Komponenten aus dem Paket wp-edit-post zurückgeben. In unserem Fall haben wir die Komponente PluginSidebar aus wp-edit-post importiert und eine Seitenleiste im Gutenberg-Editor erstellt, indem wir diese Komponente in der Render-Funktion zurückgegeben haben. Ich habe auch PluginSidebar in ein React Fragment eingefügt, da wir auch andere Komponenten in der Render-Funktion hinzufügen können. Außerdem wird die Funktion __, die aus wp-i18n importiert wurde, verwendet, damit wir jeden ausgegebenen String übersetzen können.

registerPlugin( 'myprefix-sidebar', {
  icon: 'smiley',
  render: () => {
    return (
      <>
        <PluginSidebar
          title={__('Meta Options', 'textdomain')}
        >
          Some Content
        </PluginSidebar>
      </>
    )
  }
})

Sie sollten nun neben dem Zahnrad-Symbol im Gutenberg-Editor-Bildschirm ein neues Symbol sehen. Dieses Smiley-Symbol schaltet unsere neue Seitenleiste um, die den Inhalt enthält, den wir innerhalb der PluginSidebar-Komponente haben.

Wenn Sie auf dieses Stern-Symbol neben dem Titel der Seitenleiste klicken würden, würde das Smiley-Symbol der Seitenleiste aus der oberen Symbolleiste entfernt. Daher müssen wir eine weitere Möglichkeit hinzufügen, um auf unsere Seitenleiste zuzugreifen, falls der Benutzer sie aus der oberen Symbolleiste entsternt. Dazu können wir eine neue Komponente aus wp-edit-post namens PluginSidebarMoreMenuItem importieren. Modifizieren wir also unsere Import-Anweisung.

import { PluginSidebar, PluginSidebarMoreMenuItem } from "@wordpress/edit-post";

Das PluginSidebarMoreMenuItem ermöglicht es uns, ein Element im Gutenberg-Menü hinzuzufügen, das Sie über das Drei-Punkte-Symbol oben rechts auf der Seite umschalten können. Wir möchten unser Plugin ändern, um diese Komponente einzuschließen. Wir müssen PluginSidebar eine name-Prop und PluginSidebarMoreMenuItem eine target-Prop mit demselben Wert geben.

registerPlugin( 'myprefix-sidebar', {
  icon: 'smiley',
  render: () => {
    return (
      <>
        <PluginSidebarMoreMenuItem
          target="myprefix-sidebar"
        >
          {__('Meta Options', 'textdomain')}
        </PluginSidebarMoreMenuItem>
        <PluginSidebar
          name="myprefix-sidebar"
          title={__('Meta Options', 'textdomain')}
        >
          Some Content
        </PluginSidebar>
      </>
    )
  }
})

Im Menü haben wir jetzt einen Punkt „Meta-Optionen“ mit unserem Smiley-Symbol. Dieser neue Punkt sollte unsere benutzerdefinierte Seitenleiste umschalten, da sie über die Props name und target verknüpft sind.

Großartig! Jetzt haben wir einen neuen Bereich auf unserer Gutenberg-Seite. Wir können den Text „Einige Inhalte“ in PluginSidebar ersetzen und eigene React-Komponenten hinzufügen!

Außerdem sollten wir uns die Dokumentation des edit-post-Pakets ansehen. Dieses Paket enthält viele weitere Komponenten, die Sie in Ihr Plugin einfügen können. Diese Komponenten ermöglichen es Ihnen, die bestehende Standard-Seitenleiste zu erweitern und Ihre eigenen Komponenten hinzuzufügen. Außerdem finden wir Komponenten, die es uns ermöglichen, Elemente im oberen rechten Menü von Gutenberg und auch für das Blockmenü hinzuzufügen.

Umgang mit Metadaten im klassischen Editor

Werfen wir einen kurzen Blick darauf, wie wir Metadaten im klassischen Editor mit Metaboxen verwaltet *haben*. Installieren und aktivieren Sie zuerst das Plugin Classic Editor, um zum klassischen Editor zurückzukehren. Fügen Sie dann Code hinzu, der eine Metabox auf der Editor-Seite hinzufügt. Diese Metabox verwaltet ein benutzerdefiniertes Feld, das wir _myprefix_text_metafield nennen werden. Dieses Metafeld ist nur ein Textfeld, das HTML-Markup akzeptiert. Sie können diesen Code in plugin.php einfügen oder ihn in eine separate Datei legen und ihn in plugin.php einbinden.

<?php
function myprefix_add_meta_box() {
  add_meta_box( 
    'myprefix_post_options_metabox', 
    'Post Options', 
    'myprefix_post_options_metabox_html', 
    'post', 
    'normal', 
    'default'
  );
}
add_action( 'add_meta_boxes', 'myprefix_add_meta_box' );
function myprefix_post_options_metabox_html($post) {
  $field_value = get_post_meta($post->ID, '_myprefix_text_metafield', true);
  wp_nonce_field( 'myprefix_update_post_metabox', 'myprefix_update_post_nonce' );
  ?>
  <p>
    <label for="myprefix_text_metafield"><?php esc_html_e( 'Text Custom Field', 'textdomain' ); ?></label>
    <br />
    <input class="widefat" type="text" name="myprefix_text_metafield" id="myprefix_text_metafield" value="<?php echo esc_attr( $field_value ); ?>" />
  </p>
  <?php
}
function myprefix_save_post_metabox($post_id, $post) {
  $edit_cap = get_post_type_object( $post->post_type )->cap->edit_post;
  if( !current_user_can( $edit_cap, $post_id )) {
    return;
  }
  if( !isset( $_POST['myprefix_update_post_nonce']) || !wp_verify_nonce( $_POST['myprefix_update_post_nonce'], 'myprefix_update_post_metabox' )) {
    return;
  }
  if(array_key_exists('myprefix_text_metafield', $_POST)) {
    update_post_meta( 
      $post_id, 
      '_myprefix_text_metafield', 
      sanitize_text_field($_POST['myprefix_text_metafield'])
    );
  }
}
add_action( 'save_post', 'myprefix_save_post_metabox', 10, 2 );

Ich werde nicht ins Detail dieses Codes gehen, da dies außerhalb des Rahmens des Artikels liegt, aber was er im Wesentlichen tut, ist:

• Erstellen einer Metabox mit der Funktion add_meta_box.
• Rendern eines HTML-Inputs mit der Funktion myprefix_post_options_metabox_html.
• Steuern des Metafelds namens _myprefix_text_metafield.
• Verwenden des Hook save_post action, um den Wert des HTML-Inputs abzurufen und das Feld mit update_post_meta zu aktualisieren.

Wenn Sie das Classic Editor-Plugin installiert haben, sollten Sie das Metafeld im Beitrageneditor sehen.

Beachten Sie, dass das Feld mit einem Unterstrich (_myprefix_text_metafield) präfigiert ist, was verhindert, dass es mit der standardmäßigen Custom Fields-Metabox von WordPress bearbeitet wird. Wir fügen diesen Unterstrich hinzu, weil wir beabsichtigen, das Feld selbst zu verwalten, und weil er es uns ermöglicht, es aus dem standardmäßigen Abschnitt „Benutzerdefinierte Felder“ des Editors auszublenden.

Nachdem wir nun eine Möglichkeit haben, das Feld im klassischen Editor zu verwalten, werden wir das klassische Editor-Plugin deaktivieren und zu Gutenberg zurückkehren. Die Metabox wird weiterhin in Gutenberg angezeigt. Wie wir jedoch bereits besprochen haben, empfiehlt WordPress, diese PHP-basierte Metabox mit einem JavaScript-Ansatz zu portieren.

Das werden wir im Rest des Artikels tun. Nachdem wir nun wissen, wie man Redux-ähnliche Stores zur Datenmanipulation verwendet und wie man React-Inhalte in die Seitenleiste einfügt, können wir endlich eine React-Komponente erstellen, die unsere Metafelder verwaltet und sie in die Seitenleiste des Gutenberg-Editors einfügt.

Wir wollen das PHP-basierte Feld nicht komplett abschaffen, da es immer noch nützlich ist, falls wir aus irgendeinem Grund den klassischen Editor verwenden müssen. Deshalb werden wir das Feld ausblenden, wenn Gutenberg aktiv ist, und es anzeigen, wenn der klassische Editor aktiv ist. Dies können wir erreichen, indem wir die Funktion myprefix_add_meta_box aktualisieren, um die Option __back_compat_meta_box zu verwenden.

function myprefix_add_meta_box() {
  add_meta_box( 
    'myprefix_post_options_metabox', 
    'Post Options', 
    'myprefix_post_options_metabox_html', 
    'post', 
    'normal', 
    'default',
    array('__back_compat_meta_box' => true)
  );
}

Kommen wir nun zur Erstellung der React-Komponente, die die Metadaten verwaltet.

Metadaten mit JavaScript abrufen und setzen

Wir haben gesehen, wie man den Post-Titel abruft und wie man ihn mit dem Modul wp-data ändert. Schauen wir uns an, wie man dasselbe für benutzerdefinierte Felder macht. Um Metafelder abzurufen, können wir den Speicherselektor getEditedPostAttribute aufrufen. Diesmal übergeben wir ihm jedoch den Wert meta anstelle von title.

Wenn das erledigt ist, testen Sie es in der Browserkonsole

wp.data.select('core/editor').getEditedPostAttribute('meta')

Wie Sie sehen werden, gibt diese Funktion ein leeres Array zurück, obwohl wir sicher sind, dass wir ein benutzerdefiniertes Feld namens _myprefix_text_metafield haben, das wir mit dem klassischen Editor verwalten.

function myprefix_register_meta() {
  register_meta('post', '_myprefix_text_metafield', array(
    'show_in_rest' => true,
    'type' => 'string',
    'single' => true,
  ));
}
add_action('init', 'myprefix_register_meta');

Stellen Sie sicher, dass Sie die Option show_in_rest auf true setzen. WordPress ruft die Felder über die WP REST API ab. Das bedeutet, wir müssen die Option show_in_rest aktivieren, um sie verfügbar zu machen.

Führen Sie den Konsolentest erneut aus und Sie erhalten ein Objekt mit all unseren benutzerdefinierten Feldern.

Fantastisch! Wir können den Wert unseres benutzerdefinierten Feldes abrufen. Schauen wir uns nun an, wie wir den Wert im Speicher ändern können. Wir können die Aktion editPost im Store core/editor dispatchieren und ihr ein Objekt mit einem Schlüssel meta übergeben, welches wiederum ein Objekt mit den zu aktualisierenden Feldern sein wird.

wp.data.dispatch('core/editor').editPost({meta: {_myprefix_text_metafield: 'new value'}})

Versuchen Sie nun, den Selektor getEditedPostAttribute erneut auszuführen, und der Wert sollte auf new value aktualisiert worden sein.

Wenn Sie versuchen, einen Beitrag nach der Aktualisierung des Feldes mit Redux zu speichern, erhalten Sie einen Fehler. Wenn Sie sich den Netzwerk-Tab in den DevTools ansehen, stellen Sie fest, dass der Fehler vom REST-Endpunkt wp-json/wp/v2/posts/{id} zurückgegeben wird und besagt, dass wir _myprefix_text_metafield nicht aktualisieren dürfen.

Dies liegt daran, dass WordPress jedes Feld, das mit einem Unterstrich beginnt, als privaten Wert behandelt, der nicht über die REST API aktualisiert werden kann. Wir können jedoch eine Option auth_callback angeben, die die Aktualisierung dieses Feldes über die REST-API erlaubt, wenn sie true zurückgibt, solange der Editor Beiträge bearbeiten kann. Wir können auch die Funktion sanitize_text_field hinzufügen, um den Wert zu bereinigen, bevor er in der Datenbank gespeichert wird.

function myprefix_register_meta() {
  register_meta('post', '_myprefix_text_metafield', array(
    'show_in_rest' => true,
    'type' => 'string',
    'single' => true,
    'sanitize_callback' => 'sanitize_text_field',
    'auth_callback' => function() { 
      return current_user_can('edit_posts');
    }
  ));
}
add_action('init', 'myprefix_register_meta');

Versuchen Sie nun Folgendes

• Öffnen Sie einen neuen Beitrag in WordPress.
• Führen Sie dies in der DevTools-Konsole aus, um den aktuellen Wert des Feldes anzuzeigen

wp.data.select('core/editor').getEditedPostAttribute('meta')

• Führen Sie dies in DevTools aus, um den Wert zu aktualisieren

wp.data.dispatch('core/editor').editPost({meta: {_myprefix_text_metafield: 'new value'}})

• Es wird Fehler geben, speichern Sie den Beitrag, um sie zu beheben.
• Aktualisieren Sie die Seite und führen Sie dies in der DevTools-Konsole aus

wp.data.select('core/editor').getEditedPostAttribute('meta')

Wird der neue Wert in der Konsole angezeigt? Wenn ja, großartig! Nun wissen wir, wie wir den Metafeldwert mit Redux abrufen und setzen können, und wir sind bereit, eine React-Komponente in der Seitenleiste zu erstellen, um dies zu tun.

Erstellen einer React-Komponente zur Verwaltung der benutzerdefinierten Felder

Als Nächstes müssen wir eine React-Komponente erstellen, die ein Textfeld enthält, das durch den Wert des Metafeldes im Redux-Store gesteuert wird. Sie sollte den Wert des Metafeldes haben... und hey, das wissen wir bereits, wie wir das bekommen! Wir können die Komponente in einer separaten Datei erstellen und sie dann in index.js importieren. Ich werde sie jedoch einfach direkt in index.js erstellen, da wir mit einem sehr kleinen Beispiel arbeiten.

Auch hier arbeiten wir nur mit einem einzigen Textfeld. Importieren wir also eine Komponente aus einem WordPress-Paket namens @wordpress/components. Dieses Paket enthält viele wiederverwendbare Komponenten, die Gutenberg-ready sind, ohne dass wir sie von Grund auf neu schreiben müssen. Es ist eine gute Idee, Komponenten aus diesem Paket zu verwenden, um mit dem Rest der Gutenberg UI konsistent zu sein.

Installieren wir dieses Paket zuerst

npm install --save @wordpress/components

Wir werden TextControl und PanelBody am Anfang von index.js importieren, um die beiden benötigten Komponenten aus dem Paket abzurufen.

import { PanelBody, TextControl } from "@wordpress/components";

Erstellen wir nun unsere Komponente. Ich werde eine funktionale React-Komponente erstellen und sie PluginMetaFields nennen, aber Sie können auch eine Klassenkomponente verwenden, wenn Sie das bevorzugen.

let PluginMetaFields = (props) => {
  return (
    <>
      <PanelBody
        title={__("Meta Fields Panel", "textdomain")}
        icon="admin-post"
        intialOpen={ true }
      >
        <TextControl 
          value={wp.data.select('core/editor').getEditedPostAttribute('meta')['_myprefix_text_metafield']}
          label={__("Text Meta", "textdomain")}
        />
      </PanelBody>
    </>
  )
}

PanelBody nimmt die Props title, icon und initialOpen entgegen. Titel und Icon sind selbsterklärend. initialOpen versetzt das Panel standardmäßig in einen offenen/erweiterten Zustand. Innerhalb des Panels haben wir TextControl, das ein Label und einen Wert für die Eingabe erhält. Wie Sie im obigen Schnipsel sehen können, erhalten wir den Wert aus dem globalen Speicher, indem wir auf das Feld _myprefix_text_metafield aus dem Objekt zugreifen, das von wp.data.select('core/editor').getEditedPostAttribute('meta') zurückgegeben wird.

Beachten Sie, dass wir nun von @wordpress/components abhängig sind und wp.data verwenden. Wir müssen diese Pakete als Abhängigkeiten hinzufügen, wenn wir unsere Datei in plugin.php einreihen.

function myprefix_enqueue_assets() {
wp_enqueue_script(
    'myprefix-gutenberg-sidebar',
    plugins_url( 'build/index.js', __FILE__ ),
    array( 'wp-plugins', 'wp-edit-post', 'wp-element', 'wp-components', 'wp-data' )
  );
}
add_action( 'enqueue_block_editor_assets', 'myprefix_enqueue_assets' );

Fügen wir die Komponente nun offiziell zur Seitenleiste hinzu, anstelle des Dummy-Textes, den wir zuvor als schnelles Beispiel eingefügt haben.

registerPlugin( 'myprefix-sidebar', {
  icon: 'smiley',
  render: () => {
    return (
      <>
        <PluginSidebarMoreMenuItem
          target="myprefix-sidebar"
        >
          {__('Meta Options', 'textdomain')}
        </PluginSidebarMoreMenuItem>
        <PluginSidebar
          name="myprefix-sidebar"
          title={__('Meta Options', 'textdomain')}
        >
          <PluginMetaFields />
        </PluginSidebar>
      </>
    )
  }
})

Sie sollten nun ein "Meta Options"-Panel sehen, das einen "Meta Fields"-Titel, ein Pin-Symbol und ein Texteingabefeld mit dem Label "Test Meta" und dem Standardwert "new value" enthält.

Wenn Sie in das Texteingabefeld tippen, wird nichts passieren, da wir die Aktualisierung des Feldes noch nicht handhaben. Das werden wir als Nächstes tun, aber zuerst müssen wir uns um ein weiteres Problem kümmern. Versuchen Sie, editPost erneut in der DevTools-Konsole auszuführen, aber mit einem neuen Wert.

wp.data.dispatch('core/editor').editPost({meta: {_myprefix_text_metafield: 'a newer value'}})

Sie werden feststellen, dass sich der Wert im Textfeld nicht auf den neuen Wert aktualisiert. Das ist das Problem. Wir brauchen das Feld, um durch den Wert im Redux-Store gesteuert zu werden, aber wir sehen das nicht in der Komponente widergespiegelt. Was ist los?

Wenn Sie Redux bereits mit React verwendet haben, wissen Sie wahrscheinlich, dass wir eine Higher-Order-Komponente namens connect verwenden müssen, um Redux-Store-Werte in einer React-Komponente zu nutzen. Dasselbe gilt für React-Komponenten in Gutenberg – wir müssen eine Higher-Order-Komponente verwenden, um unsere Komponente mit dem Redux-ähnlichen Store zu verbinden. Leider können wir nicht einfach wp.data.select direkt aufrufen, wie wir es zuvor getan haben. Diese Higher-Order-Komponente lebt in der globalen Variable wp.data, die auch als npm-Paket namens @wordpress.data verfügbar ist. Installieren wir es also, um uns bei der Lösung des Problems zu helfen.

npm install --save @wordpress/data

Die benötigte Higher-Order-Komponente heißt withSelect. Importieren wir sie in index.js.

import { withSelect } from "@wordpress/data";

Denken Sie daran, dass wir wp-data bereits als Abhängigkeit in wp_enqueue_script hinzugefügt haben. Wir können es also einfach verwenden, indem wir unsere Komponente damit umschließen, wie folgt.

PluginMetaFields = withSelect(
  (select) => {
    return {
      text_metafield: select('core/editor').getEditedPostAttribute('meta')['_myprefix_text_metafield']
    }
  }
)(PluginMetaFields);

Hier überschreiben wir unsere PluginMetaFields-Komponente und weisen ihr dieselbe Komponente zu, die nun mit der Higher-Order-Komponente withSelect umschlossen ist. withSelect erhält eine Funktion als Argument. Diese Funktion erhält die select-Funktion (die wir zum Zugriff auf wp.data.select verwendet haben) und sollte ein Objekt zurückgeben. Jeder Schlüssel in diesem Objekt wird als Prop in die Komponente injiziert (ähnlich wie bei connect in Redux). withSelect gibt eine Funktion zurück, die wir der Komponente (PluginMetaFields) wieder wie oben gezeigt übergeben können. Durch diese Higher-Order-Komponente erhalten wir nun text_metafield als Prop in der Komponente, und wann immer sich der Metawert im Redux-Store ändert, aktualisiert sich auch der Prop – somit aktualisiert sich die Komponente, da sich Komponenten aktualisieren, wenn sich ein Prop ändert.

let PluginMetaFields = (props) => {
  return (
    <>
      <PanelBody
        title={__("Meta Fields Panel", "textdomain")}
        icon="admin-post"
        intialOpen={ true }
      >
      <TextControl 
          value={props.text_metafield}
          label={__("Text Meta", "textdomain")}
        />
      </PanelBody>
    </>
  )
}

Wenn Sie nun versuchen, editPost mit einem neuen Metawert in Ihrem Browser auszuführen, sollte sich auch der Wert des Textfeldes in der Seitenleiste entsprechend aktualisieren!

Bis hierhin alles gut. Nun wissen wir, wie wir unsere React-Komponenten mit unseren Redux-ähnlichen Stores verbinden. Nun müssen wir nur noch den Metawert im Store aktualisieren, sobald wir in das Textfeld tippen.

Aktionen in React-Komponenten dispatchieren

Wir müssen nun die Aktion editPost dispatchieren, wann immer wir in das Textfeld tippen. Ähnlich wie bei wp.data.select sollten wir wp.data.dispatch nicht direkt in unserer Komponente aufrufen, wie hier:

// Do not do this
<TextControl 
    value={props.text_metafield}
    label={__("Text Meta", "textdomain")}
    onChange={(value) => wp.data.dispatch('core/editor').editPost({meta: {_myprefix_text_metafield: value}})
    }
/>

Stattdessen werden wir unsere Komponente mit einer weiteren Higher-Order-Komponente aus dem Paket @wordpress.data namens withDispatch umschließen. Wir müssen diese wieder in plugin.js importieren.

import { withSelect, withDispatch } from "@wordpress/data";

Um sie zu verwenden, können wir unsere Komponente umschließen – die bereits mit withSelect und erneut mit withDispatch umschlossen ist – wie folgt.

PluginMetaFields = withDispatch(
  (dispatch) => {
    return {
      onMetaFieldChange: (value) => {
        dispatch('core/editor').editPost({meta: {_myprefix_text_metafield: value}})
      }
    }
  }
)(PluginMetaFields);

Sie können sich auch ein weiteres WordPress-Paket namens @wordpress/compose ansehen. Es erleichtert die Verwendung mehrerer Higher-Order-Komponenten in einer einzigen Komponente. Aber ich überlasse es Ihnen, dies auszuprobieren, um unser Beispiel einfach zu halten.

withDispatch ist ähnlich wie withSelect, da es eine Funktion erhält, die die dispatch-Funktion als Argument hat. Das erlaubt uns, ein Objekt von dieser Funktion zurückzugeben, das Funktionen enthält, die innerhalb der Props der Komponente verfügbar sein werden. Ich habe dies so gemacht, dass ich eine Funktion mit einem beliebigen Namen (onMetaFieldChange) erstellt habe, die einen Wert erhält, die Aktion editPost dispatchiert und den Metawert im Redux-Store auf den in den Funktionsargumenten erhaltenen Wert setzt. Wir können diese Funktion in der Komponente aufrufen und ihr den Wert des Textfeldes im onChange-Callback übergeben.

<TextControl 
  value={props.text_metafield}
  label={__("Text Meta", "textdomain")}
  onChange={(value) => props.onMetaFieldChange(value)}
/>

Bestätigen Sie, dass alles funktioniert, indem Sie die benutzerdefinierte Seitenleiste im WordPress-Beitragseditor öffnen, das Feld aktualisieren, den Beitrag speichern und dann die Seite aktualisieren, um sicherzustellen, dass der Wert in der Datenbank gespeichert ist!

Lassen Sie uns einen Farbwähler hinzufügen

Es sollte nun klar sein, dass wir ein Metafeld mit JavaScript aktualisieren können, aber wir haben bisher nur ein einfaches Textfeld betrachtet. Die Bibliothek @wordpress/components bietet viele sehr nützliche Komponenten, darunter Dropdowns, Checkboxen, Radiobuttons usw. Lassen Sie uns das Niveau erhöhen und dieses Tutorial abschließen, indem wir uns ansehen, wie wir die Farbkomponente verwenden können, die in der Bibliothek enthalten ist.

Sie wissen wahrscheinlich, was zu tun ist. Zuerst importieren wir diese Komponente in index.js.

import { PanelBody, TextControl, ColorPicker } from "@wordpress/components";

Anstatt nun ein neues benutzerdefiniertes Feld zu registrieren, wollen wir der Einfachheit halber davon ausgehen, dass dieser Farbwähler vom selben Feld _myprefix_text_metafield gesteuert wird, mit dem wir uns zuvor beschäftigt haben. Wir können die ColorPicker-Komponente innerhalb unseres PanelBody verwenden und sie wird sehr ähnlich zu dem sein, was wir mit TextControl gesehen haben, aber die Prop-Namen werden etwas anders sein. Wir haben einen color-Prop anstelle von value und onChangeComplete anstelle von onChange. Außerdem erhält onChangeComplete ein Farbobjekt, das einige Informationen über die ausgewählte Farbe enthält. Dieses Objekt hat eine hex-Eigenschaft, die wir verwenden können, um den Farbwert im Feld _myprefix_text_metafield zu speichern.

Haben Sie das alles verstanden? Es läuft auf Folgendes hinaus:

<ColorPicker
  color={props.text_metafield}
  label={__("Colour Meta", "textdomain")}
  onChangeComplete={(color) => props.onMetaFieldChange(color.hex)}
/>

Wir sollten nun einen Farbwähler in unserer Seitenleiste haben, und da er dasselbe Metafeld wie die TextControl-Komponente steuert, wird sich unser altes Textfeld aktualisieren, wann immer wir eine neue Farbe auswählen.

Das ist ein Abschluss!

Wenn Sie bis hierher im Artikel gekommen sind, dann herzlichen Glückwunsch! Ich hoffe, es hat Ihnen gefallen. Schauen Sie sich unbedingt meinen Kurs an, wenn Sie mehr über Gutenberg und benutzerdefinierte Blöcke erfahren möchten. Sie können auch den finalen Code für diesen Artikel auf GitHub finden.