Vorstellung der React-Gutenberg Bridge: Headless-Block-Unterstützung für ein noch besseres Bearbeitungserlebnis

Sie sind begeistert von den Möglichkeiten, die Headless WordPress bietet, aber das Marketingteam Ihres Kunden ist an den WYSIWYG-Gutenberg-Editor gebunden.

Sehen Sie, wie die neue Gutenberg-Block-Unterstützung von Faust für Headless-Projekte die beiden zusammenbringt, um Ihre Entwicklung zu modernisieren und gleichzeitig Ihre Marketer zu stärken.

Lautsprecher:

• Teresa Gobble, Software-Ingenieurin bei WP Engine
• Blake Wilson, leitender Softwareingenieur bei WP Engine

Sitzungsfolien:

Transkript:

TERESA GOBBLE: Hallo Leute. Mein Name ist Teresa Gobble. Ich bin Softwareentwickler mit WP Engine und arbeite im Faust-Team.

Und ich bin hier mit Blake Wilson, einem leitenden Softwareentwickler, um Ihnen die React-Gutenberg-Brücke vorzustellen – Headless-Block-Unterstützung für ein noch besseres Bearbeitungserlebnis. Willkommen. Lass uns anfangen.

Heute haben wir also viel zu tun. Zunächst werde ich ein paar Dinge im Zusammenhang mit dem Problem und der Lösung, die wir für Sie haben, sowie den Wert von React-Gutenberg Bridge durchgehen. Dann gehen wir zu Blake, der uns eine Demo der React-Gutenberg Bridge in Aktion geben wird. Danach sprechen wir über ein paar technische Details. Und wir werden auch eine zukünftige Roadmap besuchen, die zeigt, was wir dafür auf Lager haben.

Hier ist also das Problem. Es gibt keine optimierte Möglichkeit, Gutenberg-Blöcke von WordPress in ein Headless-Frontend zu übersetzen. Die Lösungen, die es gibt, sind noch nicht skalierbar oder intuitiv, um ein Entwicklererlebnis zu bieten, das Headless-Entwickler erwarten können.

Die Entkopplung unterbricht auf natürliche Weise die Möglichkeit, Gutenberg-Blockinhalte im Editor zu verwenden. Und die Agenturen müssen sich fragen, wie sie es auf ihre eigene Weise oder mit wenig Anleitung von Grund auf neu machen. Und viele unbeantwortete Fragen bleiben für die Leute.

Was ist mit Styling? Was ist mit Wiederverwendbarkeit, dynamischen Blöcken, InnerBlocks? Nun, hier kommt die React-Gutenberg Bridge ins Spiel. Es ist eine Lösung in zwei Teilen – erstens eine Möglichkeit, Gutenberg-Blöcke programmgesteuert verfügbar zu machen, damit sie geparst und auf dem Headless-Frontend gelesen werden können. Dieses Stück heißt WPGraphQL Content Blocks.

Zweitens haben wir einen Konnektor, um das Einrichten und Rendern dieser Blöcke im Headless-Frontend zu erleichtern. Und das ist ein Paket namens Faust WP Blocks. Hier sehen Sie eine exemplarische Vorgehensweise, wie es mit diesen beiden Lösungsteilen funktioniert.

Das React-basierte Backend Ihrer Website hat seine Gutenberg-Blöcke, die durch das WPGraphQL Content Blocks-Plugin verfügbar gemacht werden. Es macht den block.json-Inhalt für WPGraphQL verfügbar. Es stellt es dem Plugin namens WPGraphQL zur Verfügung.

Und dann kommt es zum Connector-Paket, das die Anpassung, Erkennung und Darstellung von Blöcken ermöglicht. Und das wird tatsächlich viel mehr diskutiert, wenn wir heute über die technische Diskussion und die Demo gehen. Welchen Wert bringt dies Ihrem Team?

Nun, es ist eine eigenwillige End-to-End-Lösung, die Komplexität und Mehrdeutigkeit reduziert. Es spart Entwicklungszeit, indem es bestimmten Konventionen folgt. Es ermöglicht die Verwendung von Blöcken und Blockmustern in Kombination. Und es kann immer wieder verwendet werden. Nachdem Sie nun eine Vorstellung davon haben, wie die React-Gutenberg-Brücke funktioniert, gehen wir zu Blake, um eine Demo davon in Aktion zu sehen.

BLAKE WILSON: Danke Teresa. Hallo allerseits. Ich bin Blake Wilson. Ich bin Senior Software Engineer hier bei WP Engine.

Und ich bin im Faust JS-Team, das Faust baut. Ich habe heute eine wirklich großartige Demo für Sie, die die beiden Komponenten zeigt, die wir gebaut haben, um diese React-Gutenberg-Brücke zu orchestrieren. Also lass uns gleich loslegen.

Zu Beginn zeige ich Ihnen, was ich hier für mein Setup habe. Und dann können wir in den eigentlichen Code gehen und sehen, was wir dort haben. Also für den Anfang habe ich hier eine WordPress-Site, die auf Local läuft.

Ich habe ein paar Plugins installiert. Also habe ich das Faust-Plugin. Dies erleichtert die Vorschau und all diese guten Dinge auf Ihrer Faust JS-Site. Ich habe WPGraphQL, das für die Umwandlung Ihrer WordPress-Site in einen GraphQL-Endpunkt erforderlich ist.

Und dann habe ich WPGraphQL Content Blocks. Dies ist also eines der Plugins, die wir entwickelt haben, um diese React-Gutenberg-Brücke zu erleichtern. Diese Lösung besteht aus zwei Hauptteilen.

Wir haben also eines der Teile, um Gutenberg-Block-Daten programmgesteuert über WPGraphQL verfügbar zu machen, und dann einen anderen Teil, um diese auf Ihrem Faust JS-Frontend zu verwenden. Beginnen wir mit einem Blick auf WPGraphQL-Inhaltsblöcke und wie das funktioniert.

Also gehen wir in unsere grafische IDE. Und ich habe diese Abfrage hier eingerichtet, um die Daten einer Seite abzurufen. In diesem Fall erhalten wir also nur den Titel der Seite.

GraphQL-Inhaltsblöcke machen also einen Inhaltsblocktyp in Ihrem GraphQL-Schema verfügbar. Wenn wir also Inhaltsblöcke eingeben, wie Sie hier sehen können, erhalten wir Informationen für diese bestimmte Seite und alle Blöcke auf dieser Seite. Lassen Sie uns diese Seite durchgehen und bearbeiten und etwas Inhalt hinzufügen.

Also werden wir auf der Beispielseite vorbeischauen. Und Sie können hier sehen, dass wir ein unbeschriebenes Blatt haben. Also lasst uns weitermachen und einige Blöcke erstellen. Lassen Sie uns hier einige Spalten erstellen.

Und wir machen eine 50/50-Kolumne. Lassen Sie uns einen Absatz zu dieser Hälfte hinzufügen und dann in einem Bild zu dieser Hälfte. Also habe ich ein Bild hier in meiner Mediathek. Lass uns weitermachen und das hier einwerfen.

Und Sie können hier sehen, wir haben zwei Spalten. Wieder ein Absatz links und ein Bild rechts. Also lasst uns das aktualisieren. Und lasst uns zurück zu den WPGraphQL-Inhaltsblöcken gehen und sehen, was wir als Ergebnis erhalten.

Wie Sie hier sehen können, haben wir jetzt zwei Inhaltsblöcke. Das erste hier ist eine Kernsäule, Kernsäule. Und dann bekommen wir darin gerendertes HTML.

Das Tolle an WPGraphQL-Inhaltsblöcken ist also, dass wir auch InnerBlocks handhaben. Sie können also hier sehen, wenn wir Inhaltsblöcken einen Parameter namens flat true hinzufügen, können Sie jetzt sehen, dass wir tatsächlich alle Blöcke erhalten, die sich sogar in diesen Spalten befanden. Also übernehmen wir auch diesen Fall für Sie.

Wir erhalten eine Kernspalte, Kernspalte, Kernabsatz, Kernbild. All das wird also programmgesteuert für Sie erledigt. Und jetzt können Sie diese Blockdaten in Ihrem Frontend verwenden. Lassen Sie uns hier also etwas tiefer graben.

Nehmen wir an, wir wollen einige der Attribute dazu. Wir können das mit einer Vereinigung in GraphQL verwenden. Also machen wir es mit dem Core-Image, holen die Attribute. Und sagen wir, wir wollen zum Beispiel die Bildunterschrift.

Sie können also sehen, dass es hier keine Bildunterschrift gibt. Kehren wir zu unserer Beispielseite zurück. Wir werden fortfahren und hier eine Bildunterschrift hinzufügen. Meine Bildunterschrift. Aktualisieren Sie das.

Und wenn wir diese Abfrage aktualisieren, können wir jetzt sehen, dass wir meine Beschriftung als richtiges Attribut in WPGraphQL-Inhaltsblöcken erhalten. Das ist also Teil 1 der Lösung. Jetzt können wir tatsächlich alle unsere Gutenberg-Block-Daten abrufen und diese verwenden, um sie in unserem Frontend zu konsumieren.

Kommen wir also zu VS Code, und wir werden sehen, wie wir dieses Stück angehen. Das ist also ein Faust JS-Beispielprojekt, das ich zusammengestellt habe. Es ist sehr einfach. Es basiert auf dem Faust Scaffold Blueprint, aber mit einigen zusätzlichen Konfigurationen für die Handhabung dieser Blöcke.

Wenn wir uns also das Paket JSON ansehen, können Sie hier sehen, dass wir hier ein paar Abhängigkeiten haben, einige der üblichen Faust-Pakete, wie Core und CLI. Wir haben auch Faust-VP-Blöcke. Dies ist also eines dieser Pakete, das alle unsere Hilfsfunktionen bereitstellt.

Wir haben auch einige WordPress-Abhängigkeiten für den Umgang mit Stilen und so weiter. Sie werden hier auch feststellen, dass wir dieses WP Blocks-Verzeichnis haben. Hier befinden sich also alle unsere Blöcke für unser Frontend und fungiert als Registrierung für alle Blöcke, die wir in unserem Frontend verwenden.

Sie können sehen, dass wir eine index.js-Datei haben. Und dies ist im Wesentlichen ein Objekt, das alle Blöcke bestimmt, die wir an unserem Frontend verwenden. Sie können also hier sehen, dass wir einen Kernabsatz, eine Kernspalte, Kernspalten und ein Kernbild haben.

In Bezug auf die Einrichtung gibt es zwei Hauptteile, über die wir sprechen werden. Einer ist also der Anbieter von WordPress-Blöcken und der Betrachter von WordPress-Blöcken. Schauen wir uns also an, wie das in Aktion aussieht. Werfen wir zunächst einen Blick auf den WordPress-Blocks-Anbieter.

Und dies wird in pages_app verfügbar sein. Sie können also hier sehen, dass wir diese Komponente haben, diesen Anbieter, den Anbieter von WordPress-Blöcken. Und es akzeptiert eine Konfigurationsstütze, die Blöcke akzeptiert. Sie können also hier sehen, dass wir Blöcke aus WP Blocks, dem Index dieses Verzeichnisses, importieren und an das Konfigurationsobjekt übergeben.

Im Wesentlichen bedeutet dies also, dass der Anbieter von WordPress-Blöcken Ihre gesamte App umschließt und Ihrer gesamten App Kontext für all diese Blöcke gibt. Lassen Sie uns nun zu WP-Vorlagen in unserer einzigartigen Vorlage gehen. Und Sie können hier sehen, dass wir den WordPress Blocks Viewer mit einer Stütze von Inhaltsblöcken aufrufen. Das sind also die Blockdaten, die wir von WPGraphQL zurückbekommen.

So, das reicht zum Setup. Lassen Sie uns das hochdrehen und sehen, wie es in Aktion aussieht. Also werde ich NPM run dev ausführen, wodurch eine Entwicklungsumgebung auf localhost 3000 eingerichtet wird. Und die Seite, an der wir zuvor gearbeitet haben, war eine Slash-Beispielseite, also werde ich die localhost 3000-Slash-Beispielseite besuchen, um diese Gutenberg zu sehen Blöcke, die wir zuvor eingerichtet haben.

Wie Sie hier sehen können, haben wir die gleichen Blöcke in unserem Gutenberg-Editor. Gehen wir also zurück zu unserem Gutenberg-Editor für die Beispielseite. Und Sie können sehen, dass wir hier unsere beiden Spalten haben, das ist mein Absatz, und dann unser Bild, das dem entspricht, was wir hier auf unserem Frontend haben.

Sie sagen vielleicht, das sieht toll aus und so, aber können wir Stile ändern? Können wir die Schriftgröße ändern? Sie können sicher.

Gehen wir also zurück zu unserem Gutenberg-Editor und nehmen einige Änderungen an diesen Blöcken vor. Also fügen wir unserem Absatz hier eine Hintergrundfarbe hinzu. Lassen Sie uns auch die Größe auf groß ändern. Für dieses Bild hier machen wir es rund.

Nehmen wir die Bildunterschrift heraus. Und wir werden das aktualisieren. Und Sie können hier sehen, dass diese Stile jetzt gelten. Und Sie können sie auf Ihrem Frontend sehen.

Wir geben Ihrer Headless-WordPress-Site also wirklich das Publisher-Erlebnis zurück, das Sie in WordPress nicht erwarten. Eine weitere großartige Sache dabei ist, dass Sie jetzt, da Sie programmgesteuerte Daten für diese Blöcke erhalten, Ihre React-Komponente mit Framework-spezifischen Funktionen wie dem nächsten Bild erstellen können. Anstatt nur den HTML-Code zu rendern, den Sie von WPGraphQL erhalten, können wir jetzt diese programmgesteuerten Daten verwenden, um eine Komponente zu erstellen, die alle unsere Bilder in Gutenberg mit dem nächsten Bild rendert, was uns ein verzögertes Laden, eine bessere Leistung und besser optimierte Bilder ermöglicht insgesamt eine bessere Benutzererfahrung für unsere Benutzer schaffen.

Das ist großartig. Wir sehen genau das, was wir in unserem Gutenberg-Editor erwarten, aber sagen wir, wir fügen eine Komponente hinzu, die vielleicht noch nicht unterstützt wird oder die wir auf unserer Faust-Site nicht konfiguriert haben. Lassen Sie uns also fortfahren und hier unten eine neue Komponente erstellen. Wir verwenden Tabelle.

Und wir machen zwei Reihen – Reihe 1, Reihe 2. Gehen Sie und aktualisieren Sie das. Und wenn wir hier in unseren Code zurückblicken, können wir sehen, dass wir vier Blöcke definiert haben – Kernabsatz, Kernspalte, Kernspalten und Kernbild. Wir haben hier keine Kerntabelle.

Was wird also passieren, wenn wir diese Seite anzeigen? Lass uns einen Blick darauf werfen. Also gehen wir zurück zur Beispielseite in unserem Faust-Frontend. Und Sie können sehen, dass wir hier immer noch eine Tabelle mit Zeile 1 und Zeile 2 erhalten.

Das liegt daran, dass wir, wenn der Block in Ihrem Faust JS-Projekt noch nicht definiert ist, einen sinnvollen intelligenten Fallback auf das gerenderte HTML vornehmen. Auf diese Weise sehen Sie keinen undefinierten, null oder gar keinen Inhalt. Zumindest erhalten Sie den ursprünglich gerenderten HTML-Code zurück.

Lassen Sie uns vor diesem Hintergrund einen Blick darauf werfen, was es tatsächlich braucht, um einen Block zu erstellen – wie er tatsächlich aussieht. Also kehren wir hier zu VS Code zurück. Nehmen wir zum Beispiel das Kernbild.

Wie Sie hier sehen können, ist dies nur eine traditionelle React-Komponente. Wir nennen es Kernbild. Und es akzeptiert Requisiten, genau wie jede andere React-Komponente.

Es gibt hier im Wesentlichen zwei Teile zu einem Block. Wir haben also die eigentliche React-Komponente, die Präsentationsebene. Und dann erhalten wir die block.fragments, das sind die Daten, die für die Ausführung dieses Blocks benötigt werden.

Sie können also hier sehen, dass wir ein Fragment erstellen, Kernbildfragment auf Kernbild. Und wir erhalten diese Attribute – die Attribute, die wir zum Rendern dieses Blocks benötigen. Sie können also sehen, dass wir den Alt-Text, die Quelle, die Beschriftung, den Klassennamen, die Breite, die Höhe usw. erhalten.

Und dann können wir diese Attribute in unsere eigentliche React-Logik anwenden. Alle Felder, die hier angefordert werden, sind dann in Requisiten verfügbar. Sie können also sehen, dass props.attributes herauskommen, das sind die Attribute, die wir hier angefordert haben, attributes.alt, attributes.source und so weiter. Dies ist also eine großartige Möglichkeit, alle Datenanforderungen für Ihren Block in derselben Datei zusammenzufassen.

Dadurch stellen Sie sicher, dass Sie nur die Daten anfordern, die Sie benötigen, und stellen sicher, dass Ihre Anfragen nett und leistungsfähig sind. Wir haben auch ein paar Hilfsfunktionen in diesem Beispielprojekt. Sie können sehen, dass es hier ein paar gibt – erhalten Sie Stile und Requisiten in Bildgröße.

Diese nehmen also im Wesentlichen nur diese Stile aus WordPress und kombinieren sie zu einem tatsächlichen Stilobjekt, das React verwenden kann. Derzeit werden Stile für Inline-Stile unterstützt. Sie können auch globale Stylesheets erhalten, aber wir arbeiten derzeit daran, Unterstützung für theme.json bereitzustellen.

Daher wird Teresa in unserer zukünftigen Roadmap ein wenig darüber sprechen. Aber im Idealfall kommt ein Punkt, an dem wir alle unsere Stile und Polsterungen, Ränder usw. aus theme.json abrufen und hier im kopflosen Frontend anwenden können. Lassen Sie uns in Anbetracht all dessen in eine kurze technische Diskussion mit Teresa und mir eintauchen, um darüber zu sprechen, wo wir mit diesem Feature heute stehen und wohin wir in Zukunft gehen wollen.

TERESA GOBBLE: Danke für diese Demo, Blake. Das war großartig. Lassen Sie uns jetzt auf einige technische Details eingehen und darüber sprechen, wie das funktioniert. Das erste, was ich für Sie habe, ist, was sind die Anforderungen für die Verwendung von WPGraphQL-Inhaltsblöcken?

BLAKE WILSON: Ja, ja. Gute Frage, Teresa. Die einzige Voraussetzung für die Verwendung des Plugins ist also, dass auch WPGraphQL installiert ist. Wenn Sie möchten, dass Ihre Website mit Faust JS verbunden wird, können Sie natürlich das Faust JS-Blockpaket installieren, das das Rendern und all die guten Dinge auf dem Headless-Frontend erleichtert. Aber um Blockdaten tatsächlich verfügbar zu machen, brauchen Sie nur WPGraphQL und das Plugin WP GraphQL Content Blocks.

TERESA GOBBLE: Großartig. Wie werden auch die Blockdaten gesammelt?

BLAKE WILSON: Ja, also werden alle Blockdaten von jedem Block in WordPress gesammelt, der die Funktion zum Registrieren von Blocktypen verwendet. So ziemlich jeder Block, den Sie mit dieser Funktion verwenden, wird in Inhaltsblöcken angezeigt. Und das Tolle daran ist, dass es mit der block.json-Datei weitergeleitet wird und all diese Felder automatisch selbst beschreibt und dokumentiert. So haben Sie die gesamte Dokumentation in einem.

TERESA GOBBLE: Oh, großartig. Was für eine Zeitersparnis. Eine andere Sache, über die ich gerne ein wenig mehr mit Ihnen sprechen würde, ist, was mit einem nicht unterstützten Block passiert? Was passiert, wenn ein nicht unterstützter Block abgefragt wird?

BLAKE WILSON: Ja, das ist eine weitere großartige Frage. Es gibt zwei reale Szenarien, die hier passieren können. Es könnte also einen Fall geben, in dem Sie beispielsweise einen Block in Ihren Post-Daten haben, der inzwischen aus WordPress entfernt wurde.

Vielleicht war es eine Drittanbieter-Sperre, die entfernt wurde. Das ist also ein Fall eines nicht unterstützten Blocks, der sowohl im Faust-Frontend als auch in der WordPress-Registrierung nicht unterstützt wird. In diesem Fall geben wir tatsächlich einen Block an Inhaltsblöcke zurück, der als undefinierter Block oder unbekannter Block bezeichnet wird, damit Sie diesen entsprechend in Ihrem Headless-Frontend eingeben können. Und der zweite Teil ist, wenn ein Block in der WordPress-Registrierung unterstützt wird, aber noch nicht in Ihrem Faust JS-Frontend unterstützt wird, greifen wir in diesem Fall auf das gerenderte HTML zurück. Auf diese Weise haben Sie zumindest HTML gerendert, das angezeigt wird, nicht null oder undefiniert oder ähnliche Werte.

TERESA GOBBLE: Oh, großartig. Und das führt mich tatsächlich zu meiner nächsten Frage. Können Sie in Bezug auf Plugins von Drittanbietern auf einer Headless-entkoppelten Website ein Plugin eines Drittanbieters verwenden, indem Sie das Plugin WPGraphQL Content Blocks verwenden? Wie funktioniert das alles zusammen?

BLAKE WILSON: Ja, ja. Also für jedes Plugin von Drittanbietern, zurück zu dieser ersten oder zweiten Frage, solange sie mit der registrierten Blocktypfunktion in WordPress verbunden sind, wird dieser Block automatisch WPGraphQL-Inhaltsblöcken ausgesetzt. Solange diese Daten gerendert werden, können Sie den Block dann in Ihrem Faust JS-Frontend erstellen. Und das Tolle daran ist, sagen wir, Sie haben einen Drittanbieter-Block für ein Karussell. Sobald Sie das einmal in Ihrem Faust JS-Frontend erstellt haben, können Sie es in zukünftigen Projekten wiederverwenden.

TERESA GOBBLE: Oh, großartig. Hier kommt das Stück Wiederverwendbarkeit ins Spiel. Und mit diesem Plugin können Sie tatsächlich einen Teil dieser Lücke mit Plugins von Drittanbietern schließen, die mit den entkoppelten Websites nicht sofort funktionieren.

Wenn Sie jetzt im Chat nachsehen, haben wir tatsächlich ein Tutorial entwickelt, das den Leuten hilft, einen Block aus einem Plugin eines Drittanbieters zu erstellen. Also schauen Sie jetzt in den Chat, Sie können das sehen und darauf klicken. Gib ihm ein Lesezeichen.

Wie gehen Sie also mit Blöcken innerhalb von Blöcken um? Das kann wirklich knifflig sein. Können Sie uns ein bisschen erklären, wie das aussehen würde?

BLAKE WILSON: Sicher, ja. Wir haben also dieses Flag oder diesen Parameter, wenn Sie Inhaltsblöcke namens Flat abfragen. Und das akzeptiert entweder einen wahren oder einen falschen Wert. Wenn dies also als wahr angegeben wird, erhalten Sie tatsächlich ein flaches Array oder eine flache Liste aller Blöcke auf dieser Seite, unabhängig davon, ob es sich um eine Spalte, ein Bild oder einen Absatz handelt.

Sie erhalten eine vollständige Liste aller auf dieser Seite abgefragten Blöcke mit zwei zusätzlichen Eigenschaften. Einer ist die Knoten-ID. Das ist also die tatsächliche ID dieses bestimmten Blocks. Und dann haben Sie auch eine Eltern-ID, die der Elternteil dieses Blocks ist. Was Sie dann tun können, ist, das in eine tatsächliche hierarchische Liste auf Ihrem Frontend zu rekonstruieren und so ziemlich das innere Blockrätsel zu lösen, wie wir es zuvor in Gutenberg gesehen haben.

TERESA GOBBLE: Großartig. Gibt es also tatsächlich eine Option, die Sie beim Abrufen von Inhaltsblöcken angeben können, um eine flache Liste von Blöcken innerhalb ihrer entsprechenden Eltern-Kind-IDs zurückzugeben?

BLAKE WILSON: Ja, ja, genau.

TERESA GOBBLE: Großartig. Wir haben auch hier unten im Chat ein weiteres Tutorial für die WPGraphQL-Inhaltsblöcke, um auch einen Blick auf diese spezielle Funktion zu werfen. Also wollte ich Ihnen noch eine Frage zum Styling-Teil stellen – also Styling mit globalen Stylesheets, Inline, wie ist da der Ansatz? Wie wird gestylt?

BLAKE WILSON: Ja, ja. Das Styling ist also wahrscheinlich einer der größten Fortschritte, die wir gerade zu erforschen versuchen. In dem Beispiel, das ich gerade gezeigt habe, werden Inline-Stile verwendet.

Globale Stile, globale Stylesheets werden ebenfalls unterstützt. Und ich denke, Sie werden dies als nächstes in der Roadmap ansprechen. Aber idealerweise möchten wir auch die Unterstützung von theme.json unterstützen, wo wir Ränder, Auffüllungen, Farben und all diese guten Informationen aus der theme.json erhalten und diese dann anwenden können. Daran werden wir also in unserer nächsten Entwicklungsphase arbeiten.

TERESA GOBBLE: Großartig. Vielen Dank, dass Sie uns dabei begleitet haben. Ich weiß, dass viele Leute wirklich aufgeregt darüber sind. Wie hindern wir also den Publisher daran, Blöcke zu verwenden, die nicht unterstützt werden?

BLAKE WILSON: Ja, ja. Es gibt also ein Plugin. Es hängt davon ab, ob. Wenn Sie Blöcke von Drittanbietern verwenden, haben einige von ihnen diese Funktion bereits integriert.

Aber wenn nicht, gibt es ein Plugin namens Block Visibility, mit dem Sie bestimmte Blöcke aus der Publisher-Perspektive umschalten können. Nehmen wir also an, Sie haben einen Karussellblock, der noch nicht auf Ihrer Faust-Website implementiert wurde. Sie können die Blocksichtbarkeit installieren und diese deaktivieren, damit der Herausgeber sie nicht verwendet, solange sie noch nicht unterstützt wird oder sich in der Entwicklung befindet.

TERESA GOBBLE: Oh, großartig. Damit die Sichtbarkeit von Plugin-Blöcken tatsächlich bestimmte Blöcke umschalten, ausblenden oder anzeigen kann?

BLAKE WILSON: Ja, ja, genau. Auf diese Weise haben Sie also eine begrenzte Anzahl von Blöcken, die Sie unterstützt haben, sowohl auf Ihrer WordPress-Seite als auch auf Ihrer Headless-Site, damit die Herausgeber wissen, OK, wir können dies mit Sicherheit verwenden, dass es auf der unterstützt wird Frontend.

TERESA GOBBLE: Oh, das klingt auf jeden Fall nach einer saubereren Lieferung. OK Cool. Letzte Frage an dich. Entsprechen diese Frontend-Blöcke dem Editor des Herausgebers?

BLAKE WILSON: Ja, toller Callout. Also noch nicht. Daran werden wir in Zukunft arbeiten, aber im Moment werden diese Blöcke für das kopflose Frontend unterstützt.

Wenn Sie einen benutzerdefinierten Block haben, den Sie in WordPress erstellt haben, wenn Sie den NPX-Befehl „Block erstellen“ verwenden, müssen Sie diese Ansicht dennoch auf der WordPress-Seite unterstützen. Aber es ist etwas, woran wir arbeiten. Wir haben es in unserer Roadmap.

TERESA GOBBLE: Oh, großartig. OK. Danke, dass Sie diese Punkte mit uns besprochen haben, Blake. Das war wirklich hilfreich, und die Demo auch.

Lassen Sie uns weitermachen und den Gang wechseln und tatsächlich ein bisschen mehr über diese Projekt-Roadmap sprechen. Wir haben eigentlich fünf Phasen, von denen zwei bereits abgeschlossen sind – Phase 1 und Phase 2. In Phase 1 sahen wir eine Implementierung einer Methode zur effizienten Dekonstruktion und Rekonstruktion eines Blocks.

Danach gingen wir zu Phase 2 über, die sich auf eine engere Faust-Integration mit Gutenberg-Blöcken konzentrierte, um sicherzustellen, dass die Leute alle Zugriff auf die verschiedenen Hilfsprogramme und Hilfsfunktionen haben, die darin enthalten sind. In dieser nächsten Phase, in der wir uns gerade befinden, Phase 3, konzentrieren wir uns auf die Bereitstellung von theme.json-Unterstützung und wiederverwendbaren Blockbibliotheken, wie Blake während unserer technischen Diskussion erwähnt hat.

Nachdem wir das erledigt haben, werden Phase 4 und 5 stattfinden. Phase 4 konzentriert sich auf die Verbesserung der bestehenden Entwicklungs- und Bearbeitungserfahrung, sowie Phase 5, die sich auf die Unterstützung des breiteren Ökosystems über das Kern-WordPress hinaus konzentriert. Wir freuen uns sehr auf diese bevorstehenden Phasen und hoffen, dass Sie sich mit uns in Verbindung setzen und auch einen Blick auf unseren Blog-Beitrag werfen, um über den Stand der Roadmap auf dem Laufenden zu bleiben.

Sie können im Chat unten einen Link zu unseren Blog-Beiträgen sehen, wenn Sie einen Blick darauf werfen. Gehen Sie voran und bookmarken Sie diese. Vielen Dank an alle, die sich uns an unserer Diskussion über die React-Gutenberg-Brücke angeschlossen haben. Ich möchte Blake hier wieder auf den Bildschirm bringen, damit er sich ebenfalls bedanken und uns ein wenig mehr Informationen darüber geben kann, wohin Sie gehen können, wenn Sie danach noch Fragen haben.

BLAKE WILSON: Ja, danke, Teresa, und danke für alle, die heute an dieser Sitzung teilgenommen und zugesehen haben. Wir freuen uns sehr, Community-Feedback zu dieser Funktion zu erhalten, damit Sie alle damit beginnen können, sie auszuprobieren.

Wenn es Ihnen also gefällt, haben wir das Beispielprojekt im Link im Chat. Wir haben auch einen Link im Chat für unseren Headless-Discord, also nur einen Ort, an dem Sie und andere gleichgesinnte Headless-Entwickler teilnehmen und über kommende Funktionen und Veröffentlichungen im Headless-Bereich chatten können. Also nochmal danke an euch alle. Wir wissen das sehr zu schätzen.