Auswirkungen des Beitritts von WordPress zum Block-Protokoll

Matt Mullenweg (Erfinder von WordPress) hat Interesse daran bekundet, dass der WordPress-Editor dem Blockprotokoll entspricht, einer kürzlich veröffentlichten Spezifikation, die darauf abzielt, dass „Blöcke“ über Anwendungen hinweg portierbar sind.

Als ich von Matts Interesse erfuhr, war ich ziemlich begeistert, da eine solche Entwicklung mehrere positive Konsequenzen für WordPress und andere Akteure haben könnte. Meine Aufregung kommt von dem, was mit GraphQL passiert ist, wo die Veröffentlichung von Servern, Clients und Tools, die sich an eine gemeinsame Spezifikation halten, ein reiches Ökosystem hervorgebracht hat; und aus meiner eigenen Entwicklung eines Plugins, das neue Funktionen durch das Protokoll unterstützen könnte.

In diesem Artikel werde ich diese und einige andere mögliche Ergebnisse analysieren. Aber bevor wir das tun, lassen Sie uns den Kontext der Geschichte untersuchen: Was ist ein Block, was das Block-Protokoll erreichen soll und wie alles mit WordPress verbunden ist.

Was ist ein Block?

Bei der Arbeit mit JavaScript-basierten Bibliotheken wie React oder Vue arbeiten wir mit „Komponenten“, bei denen es sich um zusammengruppierte Codeteile (normalerweise bestehend aus HTML, CSS-Stilen und JavaScript) handelt. Eine Komponente rendert ein definiertes Layout oder erzeugt eine bestimmte Funktionalität, wie z. B. ein Bilderkarussell, einen Veranstaltungskalender oder eine einfache Kopfzeile. Zum Rendern von Inhalten kann die Komponente Daten vom Server über einen API-Aufruf abrufen oder die Daten über Requisiten von einer Vorfahrenkomponente bereitstellen lassen, die sie umschließt. Durch das Einfügen der Daten wird die Komponente wiederverwendbar und kann unterschiedliche Ergebnisse für unterschiedliche Kontexte oder Anwendungen liefern.

Ein „Block“ ist ebenfalls eine Komponente, aber auf hoher Ebene, die einen definitiven Zweck geltend macht und die Anforderungen definiert, um das gewünschte Layout oder die gewünschte Funktionalität zu erzeugen. Es ist die äußerste Komponente in der Hierarchie der Komponenten, die sich gegenseitig umschließen, sodass sie aus der Vogelperspektive betrachtet werden können.

Wir können mit Komponenten spielen, wenn wir Notion verwenden, wo jede Aktion (ob Text schreiben, eine Aufzählung hinzufügen, Tabellen erstellen oder irgendetwas anderes) durch Einfügen des einen oder anderen Blocks ausgeführt wird:

Ein Block ist ein Konzept, keine Technologie. Es kann in jeder Sprache implementiert werden: nicht nur JavaScript, um Clients zu betreiben, sondern auch eine serverseitige Sprache, um ein Layout zu rendern. Blöcke dürfen nicht mit Webkomponenten verwechselt werden, bei denen es sich um eine Sammlung von Technologien zur Erstellung von Komponenten handelt. Sie schließen sich auch nicht gegenseitig aus – wir können Webkomponenten verwenden, um einen Block zu erstellen.

Nehmen wir eine Analogie aus der agilen Welt: Wenn ein MVP oder Minimum Viable Product die geringste Arbeit ist, um ein kommerzielles Projekt zu starten und zu vermarkten, könnten wir uns den Block als MUC oder Minimum Usable Component als Grundeinheit vorstellen Arbeit, die einer Bewerbung Kohärenz und Persönlichkeit verleiht.

Was ist das Blockprotokoll?

Komponenten sind ziemlich wiederverwendbar. Wenn Sie beispielsweise in npm nach „React-Komponente“ suchen, werden zahlreiche Bibliotheken mit Komponenten erstellt, die wir sofort in unsere React-Anwendungen importieren können.

Blöcke sind jedoch eine andere Geschichte, da sie meistens für eine bestimmte Anwendung entwickelt wurden. Während der Block die Mittel bereitstellen muss, um mit ihm zu interagieren (z. B. das Anbieten einer API zum Initialisieren und Rendern oder das Verfügbarmachen eines JSON-Schemas, das beschreibt, welche Daten als Eingabe benötigt werden), hängen diese Mittel normalerweise von der Anwendung ab, in der sich der Block befindet , sodass wir einen Block nicht anwendungsübergreifend wiederverwenden können.

Hier kommt das Block-Protokoll ins Spiel. Es bietet eine Spezifikation, die Blöcke und Anwendungen erfüllen müssen, mit dem Ziel, dass Blöcke in jede Anwendung eingebettet werden können, nicht nur in die, für die sie entwickelt wurden. Genau wie bei Komponenten könnten Blöcke dann anwendungsübergreifend wiederverwendbar werden.

Wiederverwendbare Blöcke und WordPress

Seit Version 5.0 vom Dezember 2018 erfolgt die Standarderfahrung in WordPress zum Erstellen von Inhalten über Blöcke. Seit der kürzlich veröffentlichten Version 5.9 wurde diese Erfahrung auf die Erstellung von Website-Layouts durch Full Site Editing (FSE) ausgeweitet. Die moderne Erfahrung zum Erstellen von Inhalten und Themes für WordPress erfolgt jetzt über Blöcke.

Als Joel Spolsky kürzlich das Block-Protokoll der Welt vorstellte, tat er dies von seinem WordPress-basierten Blog aus. Als er erklärte, wie er Blöcke zum Verfassen seines Beitrags verwendete, schlug er vor, dass Blöcke im gesamten Web wiederverwendbar sein sollten. Dies war ein direkter Vorschlag, dass WordPress-Blöcke im gesamten Web wiederverwendbar sein sollten, dem Matt Mullenweg sofort zustimmte.

Lassen Sie uns als nächstes analysieren, welche Folgen wir von einer solchen Entwicklung absehen können, falls sie eintreten sollte.

Wer wird das Block-Protokoll verwenden?

Dies ist Joels Beschreibung, wie das Block-Protokoll entstanden ist:

„[Die Implementierung eines Blocks durch verschiedene Anwendungen] ist vollständig proprietär und nicht standardisiert.

Ich dachte, wäre es nicht cool, wenn Blöcke im Internet austauschbar und wiederverwendbar wären?

[...] Benutzer möchten vielleicht einen schickeren Block verwenden, den sie in WordPress oder Medium oder Notion gesehen haben, aber mein Editor hat ihn nicht. Blöcke können nicht einfach geteilt oder verschoben werden, und unsere Benutzer sind auf die Funktionen und Fähigkeiten beschränkt, für deren Neuimplementierung wir Zeit hatten.“

Obwohl ich Joels Motivation zu 100 % zustimme, glaube ich, dass es unrealistisch ist, von Notion oder Medium zu erwarten, dass sie ihre Blöcke mit einem öffentlich geteilten Protokoll implementieren. Warum sollten sie? Natürlich wollen sie, dass ihre Blöcke proprietär sind. Wenn Medium seine eigenen Blöcke jeder Anwendung zum Einbetten zur Verfügung stellen würde, könnte jeder über Nacht einen Medium-Klon anbieten und den Datenverkehr von ihnen wegleiten. Dasselbe gilt für Begriff. Da es sich um kommerzielle Plattformen handelt, die darauf abzielen, Benutzer basierend auf ihren fortschrittlichen Funktionen und ihrer großartigen Benutzererfahrung zu gewinnen, gibt es für sie nichts, um ihre Technologie zu verschenken (d. h. sie könnten das Protokoll immer noch für ihren eigenen internen Gebrauch einhalten, aber wir, Außenstehende werden davon nicht profitieren).

Also, wer außer WordPress möchte sich vielleicht noch an das Block-Protokoll halten? Wer wird davon profitieren?

Mein Eindruck ist folgender:

• Teams ohne großes Budget
  Anstatt ihre eigenen Blöcke von Grund auf neu zu entwickeln (was mühsam ist und daher ein engagiertes Team erfordert), könnte eine Website mit Blöcken erstellt werden, die von jemand anderem entwickelt wurden; Das Team könnte die Blöcke dann einfach für seine eigene Anwendung anpassen und möglicherweise zum Open-Source-Code der Blöcke beitragen.
• Anwendungen, die aufholen müssen, um ein überzeugendes Benutzererlebnis zu bieten
  Medium und Notion sind beliebt, weil ihre Benutzererfahrung ansprechend ist. Wenn wir eine ähnliche Benutzererfahrung für unsere Websites bieten könnten (und das zu sehr geringen oder keinen Kosten), warum sollten wir das nicht tun?
  Dies ist nicht unbedingt auf kleine Websites beschränkt, sondern kann auch bei beliebten Websites der Fall sein, die im Blockrace zurückfallen. Zum Beispiel habe ich vor einiger Zeit bemerkt, dass Mailchimp mit einem modernen blockbasierten Editor zum Verfassen von Newslettern experimentiert (ich kann diesen neuen Editor nicht mehr finden … haben sie ihn weggenommen?). Ich hatte es ausprobiert, aber es war fehlerhaft, also kehrte ich zum klassischen Split-Pane-Editor zurück (der auch Blöcke unterstützt, aber einer anderen Art, die nicht an Ort und Stelle bearbeitet werden können). Könnte Mailchimp von der Verwendung von Blöcken profitieren, die von WordPress angeboten werden?

• Content-Management-Systeme
  Ähnlich wie WordPress können auch andere CMS davon profitieren, gebrauchsfertige Blöcke zum Erstellen von Anwendungen anzubieten. Tatsächlich hat Drupal Gutenberg versucht, den WordPress-Editor auf Drupal zu übertragen. Dank des Block-Protokolls könnte diese Aufgabe einfacher zu bewältigen sein.
• Open-Source-Projekte
  Ähnlich wie bei Komponenten, die über npm verfügbar sind, ist es, wenn Blöcke wiederverwendbar wären, nur eine Frage der Zeit, bis die Community damit beginnt, Blöcke zu bauen und sie kostenlos als Open Source (ob über GitHub, den Block Hub oder woanders) zum Nutzen anzubieten jeder.

Wie werden andere davon profitieren, dass WordPress dem Block-Protokoll beitritt?

Wir haben gerade untersucht, wer davon profitieren könnte und als solcher vielleicht dem Block-Protokoll beitreten möchte. Aber darüber hinaus können wir uns fragen: Wie könnten sie davon profitieren, wenn WordPress dem Block-Protokoll beitritt?

Das ist mein Eindruck:

• Zugriff auf WordPress-Blöcke
  Die naheliegendste Antwort ist, dass alle derzeit für WordPress verfügbaren Blöcke (über den Editor und FSE) auch für ihre eigenen Anwendungen verfügbar sein werden, unabhängig davon, ob sie auf WordPress basieren oder nicht.
• Nehmen Sie am von der Community geleiteten Prozess teil, um Blöcke zu erstellen
  Das Erstellen von Blöcken ist ein zeit- und arbeitsintensiver Prozess. Das Gutenberg-Projekt brauchte 5 Jahre, um den Full Site Editor zu produzieren, und es ist immer noch in Arbeit. Und die Anzahl der Personen, die an jeder neuen Version von WordPress beteiligt sind, geht in die Hunderte, wobei die neueste Version 600 Mitwirkende übersteigt.
  Die WordPress-Community investiert kontinuierlich viele Ressourcen in die Kommunikation, um sicherzustellen, dass dieser Prozess so reibungslos wie möglich verläuft, einschließlich retrospektiver Meetings, um zu analysieren, was schief gelaufen ist, und ihn für die kommenden Versionen zu verbessern.
  Wie viele Organisationen können mit diesem ausgefeilten Prozess der Verwaltung Hunderter von Menschen mithalten, um eine gemeinsame Ressource zu produzieren? Aus diesem Grund könnte es allen zugute kommen, sich den Bemühungen der WordPress-Community anzuschließen, Blöcke zu produzieren, anstatt es alleine zu tun.
• Ein Big Adopter verleiht dem Protokoll Glaubwürdigkeit und Zugkraft
  Das Block-Protokoll wurde kaum veröffentlicht, und es ist immer noch ein Entwurf. Wer wird es verwenden? Wie wird das Projekt Zustimmung von potenziellen Stakeholdern generieren? Die Unterstützung durch WordPress sendet ein starkes Signal und schafft Vertrauen für andere, sich anzuschließen, da sie wissen, dass das Projekt Mitwirkende und langfristige Unterstützung haben wird.

Was ist drin für WordPress?

Damit WordPress für die nächsten 15 Jahre relevant ist, muss es in der Welt der modernen, hochdynamischen Anwendungen bestehen. Aus diesem Grund hat WordPress ab Version 5.0 einen Modernisierungsprozess begonnen, der dazu geführt hat, dass es sich von einer eher statischen Anwendung, die Layouts basierend auf PHP-Vorlagen auf der Serverseite rendert, zu einer immer noch statischen, aber weniger also Anwendung, die Daten von einer REST-API abruft und JavaScript-Blöcke verwendet, um Inhalte und – seit der neuesten Version 5.9 – Layouts zu rendern.

Hinweis : Es ist immer noch nicht sehr dynamisch, da die Layouts im Voraus im wp-admin generiert und in der DB gespeichert werden, anstatt auf dem Client generiert zu werden, der auf eine Aktion des Benutzers reagiert.

Diese Transformation hat eine Weile gedauert, bis sie zustande kam, angefangen im Jahr 2015, als Matt Mullenweg die WordPress-Community aufforderte, „JavaScript gründlich zu lernen“. Der Beitritt zum Block-Protokoll wäre eine weitere Station auf der Modernisierungsreise von WordPress.

Mal sehen, welche Vorteile es daraus ziehen könnte.

Das Wachstum seines Marktanteils halten

Bis heute betreibt WordPress 43 % aller Websites. Obwohl der Erfolg unbestreitbar ist, reicht er für Matt Mullenweg immer noch nicht aus, der den Wunsch geäußert hat, dass WordPress 85 % des Marktanteils erreicht. (Die Beurteilung, ob diese Haltung richtig oder falsch ist, würde den Rahmen dieses Artikels sprengen.)

Jetzt können wir uns fragen, was genau eine WordPress-Seite ist? In der Vergangenheit war die Reaktion mit ihrer monolithischen PHP-basierten Architektur ziemlich klar. Aber heutzutage bauen wir Websites basierend auf einem Stack, der mehrere Technologien umfasst. Wir haben möglicherweise ein WordPress-Backend, das ein React-Frontend betreibt und ihm Daten über die WP-REST-API zuführt. Ist das eine WordPress-Seite?

Die Antwort lautet: Ich weiß es nicht, aber es spielt möglicherweise auch keine Rolle. Wenn WordPress eine der Technologien im Stack ist, wird es weiter wachsen. Bisher konnte WordPress nur die Rolle des CMS übernehmen und die Daten verwalten, um sie dem Client zuzuführen. Aber jetzt könnte WordPress dank des Block-Protokolls eine neue Rolle übernehmen: Bereitstellung von Blöcken, um das Frontend jeder Anwendung zu betreiben.

In diesem Szenario würde WordPress eine größere Rolle bei der Erstellung von Websites einnehmen. Was dazu führen würde, dass WordPress immer noch Marktanteile gewinnt und sich stärker im Webentwicklungs-Toolkit verankert, was es schwieriger macht, jemals irrelevant zu werden.

Größerer Pool von Mitwirkenden

Durch die Verwendung der von WordPress angebotenen Blöcke werden Entwickler, die WordPress normalerweise nicht verwenden, damit vertraut gemacht und es hoffentlich zu schätzen wissen und zu Mitwirkenden am Open-Source-Code werden. Dies ist wichtig, da der Pool an Mitwirkenden größer wird (JavaScript hat beispielsweise etwa dreimal so viele professionelle Entwickler wie PHP) und vielfältigere Fähigkeiten mitbringen wird.

Weitere Verfügbarkeit von Blöcken

Unnötig zu erwähnen, dass der Block-Hub in beide Richtungen funktionieren wird: WordPress wird seine Blöcke allen anderen zur Verfügung stellen, aber auch Blöcke, die für jemand anderen codiert sind, werden verfügbar sein, um WordPress-Sites zu betreiben.

Wenn sich Mailchimp beispielsweise entscheidet, beizutreten, um WordPress-Blöcke zu verwenden, um seinen Newsletter-Editor zu betreiben, und diese dann verbessert oder seine eigenen Blöcke produziert und veröffentlicht, dann stehen diese WordPress-Plugins zur Verfügung, die Newsletter erstellen und versenden.

Entkopplung des WordPress-Editors von Gutenberg

Gutenberg ist das Projekt, das dem Blockeditor in WordPress die Grundlage gibt. Es bietet eine Engine, die die Interaktion mit Blöcken ermöglicht. Beispielsweise wird die Ausgabe der edit und save eines Blocks verwendet, um den HTML-Code im Editor zu rendern und in der DB zu speichern.

Der Blockeditor muss jedoch nicht an Gutenberg gekoppelt sein. Schließlich ist ein „Block“ ein Konzept und Gutenberg eine spezifische Implementierung. Das Block Protocol lässt sich perfekt dazwischen platzieren und fungiert als Bindeglied zwischen Konzept und Umsetzung.

Infolgedessen kann Gutenberg jetzt weggenommen werden und jede andere Implementierungs-Engine kann ihren Platz einnehmen und eine andere Erfahrung bieten, die immer noch von denselben Blöcken angetrieben wird.

Eine interessante Konsequenz ist, dass WordPress selbst von dieser Architektur profitieren kann, denn Gutenberg lebt nicht überall auf der WordPress-Seite, sondern nur auf dem wp-admin . Mit anderen Worten, die öffentlich zugängliche Website, die wir mit WordPress erstellen, verlässt sich selbst nicht auf Gutenberg; Stattdessen druckt es einfach das mit Gutenberg erstellte HTML im Backend. Aus diesem Grund habe ich bereits erwähnt, dass WordPress-Sites immer noch nicht sehr dynamisch sind.

Durch die Verwendung des Blockprotokolls zur Kommunikation mit Blöcken bräuchten wir Gutenberg nicht auf der Clientseite, um Blöcke zu verwenden. Stattdessen könnten wir eine React-Anwendung haben, die die Blöcke direkt und basierend auf Benutzerinteraktionen rendert, wodurch die Website dynamischer wird.

Die gleiche Idee kann im wp-admin funktionieren, auf jeder Seite, auf der Gutenberg noch nicht verfügbar ist (zumindest bis es soweit ist). Wenn wir beispielsweise eine Einstellungsseite bereitstellen möchten, die vollständig von Blöcken für unsere Plugins unterstützt wird, könnten wir mit dem Blockprotokoll React verwenden, um die erforderlichen Konfigurationsblöcke (Kalender, interaktive Karten, Schieberegler, Dropdowns mit Optionen oder jede geeignete Eingabe) und fügen Sie etwas PHP-Logik hinzu, um die Daten in der Tabelle wp_options zu speichern.

Einbetten von Blöcken auf der öffentlich zugänglichen Website

Wenn man den vorherigen Abschnitt etwas weiterführt, könnte der eigentliche Block in die öffentlich zugängliche Website eingebettet werden, damit Benutzer damit interagieren können.

Es gibt endlose Anwendungsfälle für eine solche Funktion, darunter:

• Anzeigen eines Kalenders für Benutzer zum Buchen von Meeting-Slots, wie es von Calendly getan wird;
• Benutzern erlauben, etwas zu zeichnen, wie es von Brush Ninja getan wird, oder Spiele zu spielen, wie mit Block-a-saurus;
• Lassen Sie Benutzer Bilder manipulieren, wie dies mit der bevorstehenden überarbeiteten Medienerfahrung mit FSE möglich sein wird.

Ein weiteres Beispiel stammt von meinem eigenen WordPress-Plugin, und die Möglichkeit, es zu unterstützen, ist der Grund, warum ich vom Block-Protokoll begeistert bin. Die GraphQL-API für WordPress wird mit einem GraphiQL-Client-Block geliefert, der das Erstellen der persistenten GraphQL-Abfrage ermöglicht:

Gleichzeitig bette ich den GraphiQL-Client auf der Dokumentationsseite ein, damit Besucher damit spielen und entdecken können, wie der GraphQL-Server funktioniert:

Mit dem Block-Protokoll könnte diese Idee, den GraphiQL-Client auf der Dokumentationsseite offenzulegen, auch den Benutzern meines Plugins gewährt werden. Dann könnten sie den GraphiQL-Block einfach in ihre eigenen öffentlich zugänglichen Websites einbetten, um zu dokumentieren, wie sie Daten von ihren eigenen GraphQL-APIs für ihre eigenen Besucher abrufen können.

Unterstützung in Gutenbergs „Collaboration“-Phase

Die Möglichkeit, Blöcke auf der öffentlich zugänglichen Website einzubetten, könnte auch für Phase 3 des Blockeditors nützlich sein, die darauf abzielt, die Zusammenarbeit zu optimieren, um ein gemeinsames Autorenerlebnis ähnlich wie bei Google Docs oder Dropbox Paper zu schaffen.

Wenn ich einen Link zu Dropbox Paper erhalte, muss ich nicht angemeldet sein, um dessen Inhalte anzuzeigen:

Ebenso könnten wir eine Client-Seite haben, die in der Lage ist, Blöcke zu rendern und mit ihnen zu interagieren, sodass auch nicht angemeldete Benutzer Feedback geben können. Diese Besucher müssten nicht auf den wp-admin der Website zugreifen, daher werden wir die Möglichkeiten zur Zusammenarbeit maximieren.

Weitere Verbesserung des „Single API For Everything“-Konzepts

Das Blockkonzept wurde eingeführt, um all die verschiedenen Möglichkeiten zum Hinzufügen von Inhalten auf der WordPress-Site zu vereinheitlichen. In der Vergangenheit konnten wir bei Verwendung des „klassischen“ Editors dynamischen Code über ein Widget oder einen Shortcode hinzufügen und das Erscheinungsbild der Website über den Customizer manipulieren. Der Block ersetzt all diese verschiedenen Mechanismen, indem er eine „einzelne API“ bereitstellt, um alle Inhalte auf der Website zu erstellen und anzupassen.

Diese Vereinfachung wurde in der Benutzeroberfläche vorgenommen. Blöcke selbst bieten jedoch nicht immer eine einzige Möglichkeit, mit ihnen umzugehen, da dynamische Blöcke erfordern, dass die gleiche Ausgabe in JavaScript und PHP gerendert wird (ersterer, um den HTML-Code für den Editor zu rendern, letzterer, um ihn zu drucken die öffentlich zugängliche Seite). Diese Situation bereitet Entwicklern Angst und fügt neuen Mitwirkenden Hindernisse hinzu.

Es gab mehrere Vorschläge, um dieses Problem anzugehen (in dieser Diskussion brillant zusammengefasst), aber keiner davon ist überzeugend genug. Auch das WooCommerce-Plugin hat sich mit einem ähnlichen Problem befasst, aber seine Lösung erscheint (mir) etwas kompliziert. Ein Mechanismus zum Erstellen von DRY-Code sollte idealerweise vom CMS bereitgestellt werden, ohne dass Hacks erforderlich sind.

Das Block-Protokoll könnte eine bessere Alternative bieten. Wenn der Entwickler dieselbe Logik nicht noch einmal in PHP codieren möchte, könnte das Rendern des Blocks stattdessen auf dem Frontend erfolgen, indem derselbe Block verwendet wird. Dies würde auf clientseitigem Rendering (CSR) statt auf serverseitigem Rendering (SSR) basieren, was nicht immer empfohlen wird (da es die Indizierung von Inhalten durch Suchmaschinen beeinträchtigen kann), aber die Option, sich für eines der beiden zu entscheiden, würde es tun ruhen auf dem Entwickler.

Als Nebeneffekt könnte diese Lösung auch mehr React-Entwickler dazu verleiten, WordPress zu verwenden.

Nutzung von Entwicklungen außerhalb des WordPress-Bereichs

Wie ich bereits erwähnt habe, könnte die Einhaltung eines gemeinsamen Protokolls zu nicht koordinierten Entwicklungen führen, die ein reichhaltiges Ökosystem hervorbringen, wie es bei GraphQL der Fall war.

SpectaQL ist beispielsweise ein Dokumentationsgenerator für GraphQL-APIs. Allein durch die Einhaltung der GraphQL-Spezifikation ermöglicht dieses Projekt die automatische Dokumentation der API, was vom Entwickler nur sehr wenig Aufwand erfordert.

Die Einhaltung des Block-Protokolls könnte ähnliche Auswirkungen haben. Wir können voraussehen, dass einige Projekte die Informationen automatisch aus block-metadata.json extrahieren und eine statische Website erstellen, die alle Blöcke dokumentiert. Dieselbe Idee wird derzeit für Gutenberg umgesetzt. Wenn ein Projekt diese Aufgabe bereits für das Blockprotokoll angegangen ist, könnte Gutenberg darauf Huckepack fahren und seine Mitwirkenden freistellen, um andere Aufgaben zu erledigen.

Verbesserte Unterstützung für GraphQL

Der andere Grund, der mich besonders reizt, ist, dass die GraphQL-Server für WordPress (WPGraphQL und meine eigene GraphQL-API für WordPress) Gutenberg derzeit nicht optimal unterstützen können, da block.json nicht den tatsächlichen Typ eines Objekts oder einer Array-Eigenschaft deklariert. Beispielsweise kann ein Block in Gutenberg eine Eigenschaft vom Typ array deklarieren, aber GraphQL muss wissen, dass es sich um ein array vom Typ String handelt.

Das Block-Protokoll empfiehlt nachdrücklich, den endgültigen Typ der Eigenschaft zu definieren:

Wo verfügbar, SOLLTEN Blöcke ein entityTypes -Feld erwarten und verarbeiten, das Entitätstypdefinitionen für alle Entitäten enthält, die an die Blöcke gesendet werden.

Wenn also WordPress-Blöcke sich an das Blockprotokoll halten, würde ihr JSON-Schema aktualisiert, um diese Informationen bereitzustellen, und die GraphQL-Plug-ins wären dann in der Lage, Blockdaten abzurufen, ohne auf Hacks zurückzugreifen.

Einpacken

In diesem Artikel habe ich einige mögliche Folgen des Beitritts von WordPress zum Block-Protokoll besprochen, was darauf hindeutet, dass dies zu positiven Ergebnissen führen wird. Ich habe jedoch nicht darauf eingegangen, wie machbar es ist, dass dies geschieht.

Ist es technisch möglich? Ist dies möglich, ohne die Abwärtskompatibilität zu beeinträchtigen? Überwiegen die potenziellen Vorteile den erforderlichen Aufwand? Macht es überhaupt Sinn, dass es ein Block Protocol gibt oder lassen sich unterschiedliche Anforderungen verschiedener Anwendungen nicht auf Blockebene unter einen Hut bringen?

All diese Fragen (und viele andere) müssen beantwortet werden, bevor die Entscheidung getroffen wird, dem Blockprotokoll beizutreten oder nicht. Da Matt Mullenweg sein Interesse bekundet hat, ist es nun an der Zeit, dass die Community abwägt und entscheidet, ob WordPress auf seiner Modernisierungsreise anhalten und in diesem neuen Hafen auftanken oder ihn überspringen und weiter segeln soll.