Drücken Sie Folgendes: WPGraphQL und Faust.js

Willkommen bei Press This, dem WordPress-Community-Podcast von WMR. Jede Episode enthält Gäste aus der ganzen Community und Diskussionen über die größten Probleme, mit denen WordPress-Entwickler konfrontiert sind. Das Folgende ist eine Transkription der Originalaufnahme.

Unterstützt von RedCircle

Doc Pop : Sie hören Press This, einen WordPress-Community-Podcast auf WMR. Jede Woche stellen wir Mitglieder der WordPress-Community vor. Ich bin Ihr Gastgeber, Doc Pop. Ich unterstütze die WordPress-Community durch meine Rolle bei WP Engine und meine Beiträge zu TorqueMag.Io, wo ich Podcasts machen und Cartoons und Tutorial-Videos zeichnen kann. Schau dir das an.

Sie können Press This bei Red Circle, iTunes oder Spotify abonnieren oder Folgen direkt bei wmr.fm herunterladen.

In dieser Folge von Press This sprechen wir über Headless WordPress, GraphQL und Faust.js. Wie diese Tools zusammen verwendet werden können und welche Kosten mit Headless WordPress verbunden sein könnten. Wir werden versuchen, tief in dieses Thema einzutauchen, und ich habe heute zwei großartige Gäste, die sich mir anschließen, ich habe Jason Bahl, einen leitenden Softwareingenieur bei WP Engine in Denver, Colorado, wo er WPGraphQL betreut . Und wir haben Chris Weigman, einen Engineering Manager, der an Faust.js arbeitet. Normalerweise beginne ich diese Shows gerne damit, Gäste nach ihren WordPress-Ursprungsgeschichten zu fragen, aber ich dachte, ich würde die Dinge hier ein wenig ändern.

Jason, können Sie uns sagen, was WPgraphQL ist und was seine WordPress-Ursprungsgeschichte ist.

Jason Bahl: Oh ja, WPGraphQL ist ein kostenloses Open-Source-WordPress-Plugin, das eine GraphQL-API auf Ihre WordPress-Site bringt, und GraphQL ist eine Graph-Abfragesprache. So können Entwickler mithilfe der Graph-Abfragesprache Inhalte in und aus WordPress abrufen.

Und das Plugin entstand, als ich vor ein paar Jahren bei einer Zeitung arbeitete und wir viel Content Syndication betrieben. Wir hatten ein Netzwerk von etwa 54 Standorten in den gesamten USA und mussten Inhalte von einer Seite zur anderen verschieben. Wissen Sie, wenn eine Nachricht veröffentlicht wurde, konnten verschiedene Zeitungen Inhalte von anderen Zeitungen abonnieren.

Als verschiedene Ereignisse eintraten, mussten wir Daten in diesem Netzwerk verschieben, und wir verwendeten die WordPress-REST-API, um einen Großteil dieser Datenverschiebung durchzuführen. Und wir hatten technisch einige Probleme damit und wie die tatsächliche Leistung technisch, aber auch die Entwicklererfahrung. Ich habe von GraphQL erfahren, der eigentlichen Graph-Abfragesprache, die 2015 von Facebook als Open Source bereitgestellt wurde.

Also habe ich diese Technologie gefunden, einige Prototypen erstellt, sie meinen Kollegen vorgestellt und dann haben wir unsere Kontaktsyndikation von REST auf GraphQL migriert. Und dann arbeitete ich weiter an dem Projekt als Community-Projekt, in dem Wissen, dass JavaScript-Frameworks immer mehr angesagt waren und dies wahrscheinlich der primäre Anwendungsfall für die Verwendung von GraphQL sein würde, da die Server-zu-Server-Kommunikation nicht der primäre Anwendungsfall ist. Es erfüllte unsere Bedürfnisse, aber ich sah eine größere Vision dafür, also arbeitete ich weiter daran als Open-Source-Projekt für die Community.

DP: Nun, cool. Chris, kannst du uns eine ähnliche Geschichte darüber erzählen, was Faust ist und wie es dazu kam?

Chris Weigman: Sicher, Faust ist seit dieser Woche offiziell für die Öffentlichkeit freigegeben, erneut für das öffentliche Framework zum Erstellen von Headless-WordPress-Sites mit GraphQL freigegeben. Nun, die Entwicklung begann im Jahr 2020, und es war eine Art inoffizielles Projekt von WP Engine, und dies ist der dritte große Dreh- und Angelpunkt.

Sie hatten es als Erweiterung von DevRel gestartet, es etwas offizieller gemacht und sich in etwas namens GQty und eine sehr JavaScript-Entwickler-zuerst-Mentalität verwandelt. Und als ich das Team am 1. Dezember letzten Jahres übernommen habe, haben wir gemerkt, dass das nicht unser Zielmarkt ist.

Wir hätten für WordPress-Entwickler entwickeln sollen. Also haben wir angefangen, es wieder aufzubauen, und das konnte vor kurzem endlich wieder veröffentlicht werden.

DP: Jason, du hast kürzlich getwittert, dass du das neue wpgraphql.com auf Faust.js gestartet hast. Ich glaube, die vorherige Seite war kopfloses WordPress. Können Sie uns etwas über diese Änderung erzählen, die Sie vorgenommen haben, und wissen Sie, welche Verbesserungen Sie sagen?

JB: Ja. wpgraphql.com ist also seit vielen Jahren eine Headless-Site. Also verwende ich mehrere Datenquellen. Ich habe also viele Inhalte in WordPress, so wie die Blog-Posts alle in WordPress sind.

Ein Teil der Dokumentation existiert auch in WordPress. Und dann gibt es einige Dokumentationen in Markdown-Dateien im GitHub-Repo. Die längste Zeit, in der ich Gatsby verwendet habe, vielleicht drei Jahre lang, habe ich Gatsby verwendet, ein JavaScript-Framework, das im Kern eine Datenschicht hat, in der Sie Daten aus mehreren Quellen abrufen können.

Also habe ich das verwendet, es würde Daten von GitHub ziehen, Daten von WordPress auch mit WPGraphQL ziehen und mir erlauben, diese Daten zum Erstellen meiner Vorlagen zu verwenden. Also ich habe das ein paar Jahre benutzt. Es gibt viele Schmerzpunkte mit der Datenschicht, aus denen ich irgendwie herauskommen wollte.

Also wollte ich Next verwenden, worauf Faust aufbaut. Es ist ein weiteres JavaScript-Framework, aber es fehlten viele Teile, denke ich. Als nächstes, und viele dieser JavaScript-Frameworks haben die Idee, dass Ihre Front-End-Frameworks das gesamte Routing definieren sollten, richtig? Aber wenn Sie ein CMS verwenden, definiert Ihr CMS das Routing.

Und so gibt es eine Menge technischer Probleme, diese Dinger dazu zu bringen, gut zu spielen, wo zum Beispiel Ihr Frontend eine Meinung zu etwas hat und Ihr Backend eine andere Meinung hat. Eines der Probleme, die ich zu lösen versuchte, war also, mein Frontend dazu zu bringen, zu erkennen, dass eine bestimmte URL eine bestimmte Art von Sache war, und dann eine Vorlage zu rendern, die diese Sache darstellte.

Zum Beispiel hat ein Blogbeitrag eine andere Vorlage als ein Dokument oder ein Benutzerarchiv oder was auch immer. Also wollte ich, dass mein Frontend in der Lage ist, eine URL an das CMS zu senden, Daten zurückzubekommen, aber zu verstehen, welche Vorlage zurückgegeben werden soll. In WordPress heißt es Template-Hierarchie. Und als das Faust-Team dieses Problem lösen konnte, dachte ich, verdammt, ja, ich wechsele zu Faust.

Also, ja, ich bin in der Lage, einige der Konzepte, die im Kern von WordPress vorhanden sind, wie PHP-Themen, zu nehmen und sie in Headless zu verwenden, damit ich die Vorteile von React und was auch immer für JavaScript ich am Frontend verwenden möchte, nutzen kann, um meine Vorlagen zu erstellen Seite, aber immer noch vertraute Konzepte aus der WordPress-Welt.

DP: Chris, du hast erwähnt, dass Faust einige Veränderungen erfahren hat. Was waren das für Änderungen? Weißt du, Jason hat sie erwähnt. Welche Änderungen haben diese Verbesserung ermöglicht?

CW: Es konzentriert sich immer auf WPGraphQL. Es war alles andere, was wirklich das Problem war. Zum Beispiel verwendete die letzte Hauptversion von Faust eine darunter liegende Bibliothek, um mit GraphQL namens GQty zu interagieren, was auf dem Papier wirklich cool klang. Die Idee stammte damals vom Faust-Team, dass, mal abstrahieren, die Leute nicht wissen müssen sollten, wie man diese komplexen Abfragen erstellt.

Dieses Framework sollte das für Sie abstrahieren. Auf dem Papier sah das wirklich gut aus, in der Praxis wegen der ganzen Komplexität der WordPress-Daten. Sogar ein einzelner Beitragstyp kann so viele Variationen haben. Vielleicht verwechselst du das mit Kategorie, vielleicht mit all den verschiedenen Dingen. GQty konnte es einfach nicht durchschalten.

Darüber hinaus wurde, als es mit der GQty-Version erstellt wurde, dem Routing-Problem, von dem Jason sprach, wirklich keine Aufmerksamkeit geschenkt. Wer übernimmt das Routing? WordPress möchte sein Routing nach dem Inhalt handhaben, es ist ein Content-Management-System, also ist das gesamte Routing und WordPress weitgehend inhaltsbasiert.

Next.js ist ein Frontend-Framework, also basiert das gesamte Routing auf einem völlig anderen Paradigma für die Grundlage des Routings. Was /Blog on Next sein könnte, hat möglicherweise nichts mit Inhalten für ein Blog zu tun. Es geht um eine Reihe von Vorlagen. Es wird Teil der Anwendung, die ein Blog erstellen kann.

Während /Blog auf WordPress sehr gut bedeuten könnte, dass dies alle Blog-Posts sind. Und dieses Paradigma beim Erstellen, wenn Sie WordPress zu einem sehr soliden Frontend oder einem Headless-fähigen CMS machen wollen, mussten wir uns mit diesem Routing befassen. Eine weitere Änderung, als wir dies vorgenommen haben, wie ich bei der GQty-Version sagte, war unser Ziel, JavaScript-Entwickler zu verwenden, die WordPress verwenden mussten, was edel erscheint, bis Sie erkennen, dass dies WP Engine ist.

Wir haben es mit Agenturen zu tun, die jahrelang auf WordPress aufgebaut haben und nun aus verschiedenen Gründen, auf die wir später noch eingehen können, in eine kopflose Sache übergehen. Sie wissen, wie man WordPress entwickelt. Sie verstehen, wie WordPress-Template-Routings funktionieren und wie Templates funktionieren, solche Dinge.

Wir müssen diese Funktionen voranbringen, damit GraphQL von WordPress-Entwicklern einfacher verwendet werden kann. Und das war das Ziel von Faust hier. Die Vorlagenhierarchie baut einfach neu auf, was WordPress getan hat. Wenn Sie jetzt das Routing von Next verwenden möchten, gibt es Möglichkeiten, es in der App zu überschreiben, damit Sie nichts verlieren.

Aber für Leute, die WordPresses als echtes Content-Management-System verwenden, das Inhalte durch Content-Management weiterleiten kann, wird Faust das dann viel besser für Sie handhaben? Ist das sinnvoll?

DP : Ja. Absolut. Weißt du, ich denke, das ist ein guter Ort, um hier eine kurze Pause zu machen. Sie hören gerade Press This, einen WordPress-Community-Podcast mit Chris Weigman und Jason Bahl. Wir werden wiederkommen, um über WordPress und Headless zu sprechen. Bleib dran.

DP: Wir sind zurück mit Press This. Und wissen Sie, Chris, kurz vor dieser Pause haben Sie etwas erwähnt, Sie haben erwähnt, dass immer mehr Unternehmen kopflos werden, und ich weiß, dass WP Engine eine Menge Nachforschungen angestellt hat, um zu zeigen, dass dies der Fall ist. Ich frage mich irgendwie, Headless hat definitiv einen Ruf als etwas, ich denke Unternehmen, wenn ich Headless denke, denke ich richtig. Ist das Headless? Handelt es sich nur um ein Tool für Unternehmen oder um ein Tool, das mehr Websites verwenden werden?

CW: Ja und nein. Weitgehend kopflos, insbesondere mit WordPress im Moment, bedeutet die damit verbundene Komplexität, dass Sie wahrscheinlich ein komplettes Team haben, das baut, was Sie brauchen.

Dies ist nicht jemand, der WordPress sofort verwendet, Sie möchten nur Ihren persönlichen Blog. Es kann das tun, aber es ist bisher ein viel schwererer Lift, um das tun zu können. Dasselbe gilt für Contentful, dasselbe gilt für all diese anderen CMS. Wenn Sie nur etwas Einfaches wollten, etwas, das, Sie wissen schon, die Art von Inhalten, die seit Jahren im Web sind, Headless ist wahrscheinlich mehr Arbeit, als Sie bisher bewältigen möchten.

Handelt es sich ausschließlich um Unternehmen? Schau, nein. Gatsby arbeitet seit Jahren an diesem Problem. Sie haben später noch einen Podcast, Doc with Mastodon. Es ist eine Gemeinschaft, in der ich mich seit einigen Jahren engagiere. Die meisten Leute verwenden Variationen von Headless-CMS, insbesondere Gatsby, aber da ist Hugo. Es gibt alle Arten von unterschiedlichen, diese Art von Technologie auf einer sehr grundlegenden Ebene.

Sie landen also bei den Grassroots-Benutzern und Sie landen bei den Unternehmensbenutzern für schwere Websites, während WordPress traditionell bei allen anderen dazwischen zu liegen scheint. Es ist die Person, die nicht mit Markdown-Dateien und Code umgehen möchte, wie es ein Gatsby-Benutzer tun könnte, oder Sie wissen schon, einfach nur Gatsby aus der Box.

Aber es ist auch nicht jemand, der ein ganzes 10-köpfiges Team hat, das sein persönliches Branding oder seinen persönlichen Blog aufbaut. Dies nimmt WordPress aus dieser Mitte heraus und erweitert es sehr einfach zu beiden Enden. Jetzt können Sie problemlos zwischen GraphQL aufbauen, Sie haben alle Daten und Sie haben eine ständig wachsende Anzahl von Möglichkeiten, diese Daten zu verarbeiten.

Und Faust macht es viel einfacher, das zu nutzen und etwas, das Sie an einem Tag statt in einem Monat bauen können.

DP: Jason, Chris hat etwas erwähnt, worüber ich gerne Ihre Meinung hören würde, ich habe gehört, dass dies vielleicht nicht großartig für kleine Teams ist, kleine Blogger wie ich, was offensichtlich Sinn macht, ich brauche kein kopfloses WordPress, aber so , ich denke, was ich mich frage, ist, wird mich kopfloses WordPress mehr kosten, weil ich einen iOS-Entwickler und einen WordPress-Entwickler haben muss? Ist es teurer oder ist es irgendwie kostengünstiger?

JB: Hängt wahrscheinlich davon ab, was du produzierst, denke ich. Wenn Sie, wie Sie iOS erwähnt haben, eine native mobile App verwenden, sind damit offensichtlich Kosten verbunden, und es gibt keinen wirklich guten Weg, dies zu tun, wenn Sie Daten aus WordPress oder anderen verwenden als es kopflos zu tun, denn Sie wissen, dass eine native App PHP nicht rendert, also müssten Sie das kopflos tun.

Aber wenn Sie gerade in traditionellem WordPress für das Web bauen, können Sie ein Thema finden, Sie kennen entweder ein kostenloses Thema oder ein Thema auf einem Marktplatz finden, es herunterladen, installieren und fertig zu den Rennen. Die meisten Leute werden es auf die eine oder andere Weise anpassen.

Also haben Sie normalerweise Entwicklerkosten, egal ob Sie es selbst oder jemand anderes tun. Eines der Dinge, die sich bei Headless WordPress vom traditionellen PHP-Thema unterscheiden, ist, dass ich zum Beispiel beim Start des neuen wpgraphql.com dieselbe Instanz von WordPress verwenden konnte, die meine Gatsby-Site unterstützte.

Ich bekomme die Daten, die Daten kamen heraus und gingen in die Gatsby-Site, ich konnte weiterhin Inhalte im CMS veröffentlichen und gleichzeitig mein nächstes Frontend dafür entwickeln. Bei der traditionellen WordPress-Entwicklung müssen Sie Ihre Website normalerweise in eine Art Staging-Umgebung migrieren.

Aktivieren Sie ein neues Thema in dieser Umgebung, bauen Sie Ihr Thema dort auf, beschäftigen Sie sich mit einer Art Content-Freeze-Periode, in der Sie Ihren Content-Erstellern sagen: „Hey, heute können Sie keine Inhalte veröffentlichen, weil wir migrieren und dann Wir werden die neue WordPress-Instanz einrichten, die Live-Instanz.“ Und dann müssen Sie sich dort anmelden und anfangen, Ihre Inhalte richtig zu machen.

Headless WordPress, ich konnte meine Seite auf einem völlig anderen Frontend-Stack neu aufbauen, ohne irgendetwas in meiner eigentlichen WordPress-Instanz zu stören, es ist eine Trennung von Daten und Präsentation, richtig? Also könnte ich gehen, wenn ich morgen die nächste heiße Technologie erkunden wollte, als könnte ich meinen Blick auf Svelte anstatt auf Next richten, und ich müsste nichts in WordPress ändern.

In einigen Fällen kann es also tatsächlich billiger sein, weil der ganze Prozess, einen anderen Server hochzufahren, Ihr Team dazu zu bringen, mit dem Schreiben von Inhalten aufzuhören und dann in eine andere Instanz von WordPress zu wechseln und dann dort mit der Veröffentlichung zu beginnen, Delta-Migrationen durchzuführen, solche Dinge, das kostet auch.

Eine andere interessante Sache ist, dass das JavaScript-Ökosystem wirklich ausgeliefert wird. Der gemeinsame Antrieb, meiner Meinung nach, einer der gemeinsamen Motivatoren für das Headless-Moving sind komponentenbasierte Architekturen. Und es gibt alle Arten von Komponentenbibliotheken im React- und VUE-Ökosystem, mit denen Sie Komponenten projektübergreifend wiederverwenden können.

Auf diese Weise können Agenturen gemeinsame Komponenten erstellen, die sie in Projekten verwenden, und sie können diese an einem zentralen Ort aktualisieren, sie dann aber in mehreren Projekten installieren. Bei WordPress ist das nicht ganz so einfach, da Ihre PHP-Vorlagenteile und WordPress normalerweise sehr eng mit dem Projekt gekoppelt sind, zu dem sie gehören.

Mit Headless können Sie ein MPM-Paket haben, das diese Komponenten enthält, und mehrere Projekte können dieses Paket aktualisieren und gleichzeitig mit weniger Aufwand davon profitieren. Also ich denke im Moment, ich würde sagen, es ist wahrscheinlich teurer und arbeitsaufwändiger, aber ich denke, Tools wie Faust, die es bis vor kurzem nicht gab, senken den Gesamtaufwand, der erforderlich ist, um Headless zu bauen.

Und ich denke, in nicht allzu ferner Zukunft könnte es billiger sein, kopflos zu bauen als nicht kopflos.

DP: Chris, wolltest du etwas hinzufügen, worüber Agenturen in Bezug auf die Kosten von Headless WordPress nachdenken müssen?

CW: Ich denke, Jason hat wirklich den Nagel auf den Kopf getroffen.

Und das ist eine Sache, die ich an WPGraphQL mag, ist, dass mein Team als nächstes daran arbeitet, WordPress in diese Richtung zu erweitern, mit dem, was wir nennen, unser Arbeitstitel ist die React Gutenberg Bridge, aber es ist auch ein Problem in WordPress. Wie können Sie diese Komponenten wiederverwenden? Ich möchte das Wort „nur Komponente“ nicht verwenden, weil es auf der WordPress-Seite nicht so zutrifft wie auf der JavaScript-Seite, richtig?

Aber wie verwenden wir Code projektübergreifend wieder, Headless oder auf andere Weise mit WordPress, und Headless ermöglicht dies. Aber ich denke, man kann mit Sicherheit sagen, dass der durchschnittliche Blogger nur versucht, seine Foodie-Blogs herauszubringen, und sich wahrscheinlich nicht selbst damit befasst. Das ist sehr viel ein Agenturproblem. Kostet das mehr?

Vielleicht, vielleicht auch nicht, aber hier wird es kompliziert, wenn wir darüber sprechen, wo die Kosten dafür liegen? Weil es verschiedene Arten gibt, wie Sie Daten verwenden möchten.

DP: Ja, absolut. Weißt du, ich komme aus einem Zeitungshintergrund, arbeite an Weeklys in den Twin Cities und in Nashville, Jason, ich kann mir vorstellen, wie es gewesen wäre, deinen 56 Zeitungen zu sagen, dass sie einen Tag lang nichts veröffentlichen sollen.

Heute gibt es keine Neuigkeiten, da wir die Seite aktualisieren.

JB: Ja. Und ich meine, wir haben diese Perioden durchgemacht, richtig? Als ich dort eingestellt wurde, waren sie nicht auf WordPress, und so bestand ein Teil meiner Arbeit darin, sie von einem anderen System zu WordPress zu bringen. Es gab also definitiv Tage, an denen es so war, in Ordnung, es wird am WordPress-Tag live geschaltet. Hör auf, was du tust. Rechts.

Also gab es definitiv solche Perioden oder wir mussten uns auch mit diesem Problem befassen, okay, sie haben gestern Abend bis Mitternacht auf dem alten System veröffentlicht, aber wir hatten das WordPress zwei Tage vorher startbereit. Also müssen wir jetzt eine Delta-Migration machen und sicherstellen, dass alle Daten immer noch synchronisiert sind, damit diese Prozesse definitiv technische und menschliche Kosten verursachen.

DP: Ja. Und ich denke, es gibt auch eine Menge, wenn Sie noch WordPress verwenden, erhalten Sie immer noch dieses Ökosystem, mit dem Sie diese Kosteneinsparungen erzielen können. Sie müssen die SEO-Tools nicht erstellen.

Sie können das Yoast SEO-Plugin oder was auch immer verwenden. Obwohl Sie eine Headless-Site sind, gehe ich davon aus, dass die meisten Plugins weiterhin funktionieren, solange sie nicht nach vorne gerichtet sind.

JB: Ja. Das ist eigentlich eine interessante Sache. Der neue Faust ist also mit einer Plugin-Architektur selbst gebaut. Also wie aus der Box wird es mit einem Client kommen, es verwendet den Apollo-Client, damit Sie Daten von WPGraphQL abrufen können, Sie können Ihre WordPress-Daten abrufen, aber Sie können Plugins erstellen, damit Sie, sagen wir, Sie haben es getan, wie Sie wie bereits erwähnt, installieren Sie Yoast SEO auf Ihrer WordPress-Seite.

Sie können ein Yoast-Plugin hinzufügen. Es existiert noch nicht, aber es kann bald. Sie könnten ein Yoast-Plugin für Faust im Frontend hinzufügen, das weiß, was mit diesen Daten zu tun ist, oder? Es wird also die Möglichkeit für Leute geben, einige könnten wir produzieren und unterstützen, aber einige, die Community kann auch Plugins für die Faust-Seite der Dinge produzieren und unterstützen, so dass Sie mit nur einer Codezeile dieses Plugin hinzufügen können Holen Sie sich Funktionen wie Yoast für Ihr kopfloses Frontend.

Es ist etwas, von dem ich glaube, dass kein anderes kopfloses Frontend wirklich das Konzept hat, wie Faust es angeht. Also ich denke, das Plugin, ich denke, es ist eine andere Sache, die WordPress-Entwicklern bekannt ist. Es bringt bekannte Konzepte aus WordPress mit, verbindet es aber mit dem modernen JavaScript-Frontend-Stack.

DP: Das ist ein guter Ort für eine letzte Pause hier bei Press This, und wenn wir zurückkommen, beenden wir unser Gespräch mit Chris Weigman und Jason Bahl. Bleib dran.

DP: Sie hören Press This, einen Podcast der WordPress-Community. Ich bin Ihr Gastgeber, Doc Pop. Heute sprechen wir über WPGraphQL, Faust und wie Sie Ihre Headless-WordPress-Site mit Strom versorgen können. Kurz vor der Pause haben wir über Faust und Plugins gesprochen und ich werde euch allen nur ein paar zufällige Fragen stellen und einfach mal sehen, ob hier irgendwelche guten Antworten auftauchen.

Aber Chris, ich frage mich irgendwie, mit Faust, gibt es ein Potenzial, ich weiß, es ist eine kopflose Plattform, aber gibt es ein Potenzial für ein WordPress-Faust-Thema, das Sie zumindest irgendwie dazu bringt, mit wie Hier sind die Plugins, die Sie brauchen, und hier ist einfach alles sofort einsatzbereit.

KW: Absolut. Tatsächlich haben wir es bereits. Wir bezeichnen es als Blueprints, weil es so gut mit Local funktioniert. Die meisten Leute werden an diesem Zeug eine Art Optimierung vornehmen, bevor sie es auf einer Plattform wie WP Engine starten. Also haben wir uns den Namen Blueprints von Local geliehen.

Für den neuen Faust haben wir eins namens Portfolio, das im Grunde ein vollständiges Portfolio-Thema ist, und wir arbeiten nur an einem sehr leeren Gerüst, das Agenturen verwenden können. Sobald Sie den Dreh raus haben, möchten Sie wahrscheinlich alles selbst anpassen. Ein Scaffold wäre also die Best Practice für Projekte, drehen Sie das hoch, und dann können Sie all Ihre eigenen Sachen damit machen.

Langfristig haben wir sehr viel über einen kopflosen Themenladen gesprochen, ala Blueprints. Wir haben nicht die nötige Arbeitskraft, also ist es ein bisschen weit weg, aber es ist absolut etwas, das wir in Betracht ziehen und das wir gerne sehen würden.

DP: Ja, das ist cool, darüber nachzudenken. Das ist eine ganz andere Art von Ökosystem, in das man hineinkommt.

Und wissen Sie, Jason, ich habe Sie schon einmal interviewt, und ich bin sicher, dass diese Frage die ganze Zeit auftaucht, aber jedes Mal, wenn ich von WPGraphQL höre, denke ich, dass das sehr nach dem klingt, was die REST-API tut. Eigentlich klingt das viel leistungsfähiger als das, was die REST-API tut, und die REST-API ist Teil des Kerns, und ich frage mich nur, ob Sie der Meinung sind, dass WPGraphQL Teil des WordPress-Kerns sein sollte?

JB: Vielleicht eines Tages. Ich glaube, wir sind noch nicht da. Wenn Dinge in WordPress Core zusammengeführt werden, wahrscheinlich mit Ausnahme von Gutenberg, hört die Innovation auf. Bei der REST-API zum Beispiel gibt es immer noch einen Fehler, auf den ich die Leute hinweise, der, glaube ich, noch von 2016 existiert Änderungen müssen also viel langsamer vorgenommen werden. Wenn es sich um ein Plugin handelt, können Sie die Leute für die Version entscheiden lassen, für die sie sich entscheiden möchten, und Sie können viel schneller iterieren, da sie auswählen können, welche Version für ihr Projekt am besten geeignet ist.

Wo im Kern, wenn Sie den Kern aktualisieren und er Breaking Change enthält, haben Sie vielleicht gerade 40 Prozent des Webs kaputt gemacht. GraphQL ist also eine Spezifikation, es hat auch nichts mit WordPress zu tun.

Rechts. Und so entwickelt sich die GraphQL-Spezifikation immer weiter. Und während sich das weiter entwickelt, wollen wir mit den neuesten und besten GraphQL-Spezifikationen Schritt halten. Wenn wir, sagen wir, WPGraphQL heute in Core zusammenführen würden und GraphQL sich ständig weiterentwickelt, würde WordPress bei der Ausgabe 2022 von GraphQL stecken bleiben, wo der Rest der Welt auf der Version 2030 oder was auch immer ist. Ich denke, es könnte irgendwann Sinn machen, dass es anerkannt wird, dass WPCLI der offizielle Weg ist, X-Ding zu tun.

Als könnten Sie Ihren eigenen CLI-Client für WordPress erstellen, aber es wird von der Community irgendwie anerkannt, dass WPCLI die offizielle Sache ist. Es ist nicht Teil von WordPress Core, wird aber von der WordPress Foundation und dem größten Teil der WordPress-Community als offiziell anerkannt. Es könnte also irgendwann nett sein, wenn ein WPGraphQL so erkannt wird, wie wenn Sie kopfloses WordPress machen, machen Sie es so.

Es wird immer noch ein Plugin bleiben. Das ist mein Gedanke. Es könnte eine Zeit geben, in der sich GraphQL perfekt anfühlt und nicht wirklich iteriert wird, und vielleicht ziehen wir es zu diesem Zeitpunkt in Betracht. Aber zu diesem Zeitpunkt kommen Dinge in die GraphQL-Spezifikation, die dazu führen werden, dass die API bahnbrechende Änderungen erhält.

Also macht es für mich immer noch Sinn, es als Plugin zu machen.

DP: Genau. Und ja, Sie haben WPCLI erwähnt und ich vergesse immer wieder, als ob sie einfach das Gefühl haben, dass es Teil des Kerns ist. Was auch immer es fühlt, es ist wie offiziell. Also ja, es ist wie, oh ja, das ist so eine unabhängige Sache, genau wie WPGraphQL es im Moment ist.

Das ist eine gute Analogie. Also werde ich, ich werde hier abschließen. Es war wirklich toll, mit euch beiden zu plaudern. Wenn die Zuhörer daran interessiert sind, einem von Ihnen zu folgen, können Sie @JasonBahl und @ChrisWeigman folgen. Wir werden die Twitter-Handles in die Showbeschreibung einfügen, wenn wir können. Sie haben sich Press This angehört, einen Podcast der WordPress-Community auf WMR.

In der Folge nächste Woche sprechen wir mit Anne McCarthy, einer Produktkontaktperson bei Automatic, über Änderungen an der Site-Bearbeitung und 6.1 und darüber, was mit 6.2 auf uns zukommt. Nochmals vielen Dank für das Hören von Press This.

Sie können meinen Abenteuern mit dem Torque-Magazin auf Twitter @thetorquemag folgen oder Sie können zu torquemag.io gehen, wo wir jeden Tag Tutorials, Videos und Interviews wie dieses beisteuern. Schauen Sie sich also torquemag.io an oder folgen Sie uns auf Twitter. Sie können Press This auf Red Circle, iTunes, Spotify abonnieren oder es jede Woche direkt bei wmr.fm herunterladen. Ich bin Ihr Gastgeber Doctor Popular Ich unterstütze die WordPress-Community durch meine Rolle bei WP Engine. Und ich liebe es, jede Woche Mitglieder der Community auf Press This hervorzuheben.