Ich frage mich, wo sich Headless WordPress positionieren wird. Und mit "Headless" meine ich nur die Nutzung des WordPress-Adminbereichs und die Erstellung der benutzerorientierten Website über die WordPress REST API anstelle der traditionellen WordPress-Theme-Struktur.
Ist es... groß? Die Zukunft von WordPress? Oder relativ nischig?
Wo ist die Nachfrage?
Sicher gibt es Nachfrage danach. Ich kenne viele Leute, die das tun. Zum Beispiel gibt es für Gatsby ein gatsby-source-wordpress Plugin, mit dem man Inhalte von einer WordPress-Website beziehen kann, indem man die WordPress REST API nutzt und sie als GraphQL für die Verwendung in einer React-basierten Gatsby-Website zwischenspeichert. Es wurde diesen Monat 59.000 Mal heruntergeladen und insgesamt 851.000 Mal, während ich das schreibe. Das ist eine ordentliche Nutzung für *eine* bestimmte Webtechnologie. Buchstäblich *jede* Verwendung von gatsby-source-wordpress nutzt WordPress headless – das ist einfach, was es ist/tut. Wenn Sie daran interessiert sind, hier vertieft Ganesh Dahal in das Thema.
Und das ist nur eine Sache, hier sind noch nicht einmal ganze Unternehmen und Produkte berücksichtigt, die sich dieser Idee verschrieben haben.
Was ist Headless eine Verbesserung *für*?
Die Gatsby-Integration liefert ein solides Argument dafür, *warum* man eine headless WordPress-Website in Betracht ziehen sollte. Dazu komme ich noch.
Viele befürworten es aus *architektonischen* Gründen. Es entkoppelt das Backend vom Frontend. Es reißt den Monolithen nieder. Als entkoppeltes System können Backend und Frontend unabhängig voneinander weiterentwickelt werden. Dennoch bin ich dieser Idee mit den Jahren weniger zugeneigt. Zum Beispiel würde ich argumentieren, dass die Chancen, WordPress einfach auszutauschen und durch ein anderes CMS in einem solchen headless Setup zu ersetzen, leichter gesagt als getan sind. Auch die Idee, die WordPress API nicht nur für eine Website, sondern auch für eine native Lese-App und vielleicht für eine digitale, internetverbundene Autobahnwerbetafel zu nutzen, ist nach meiner Einschätzung keine explodierende Anwendungsfall-Popularität.
Der wirkliche Grund, warum Leute meiner Meinung nach ein WordPress-Backend für ein Gatsby-gesteuertes Frontend wählen, ist im Grunde dieser: Sie mögen React. Sie bauen gerne Dinge aus Komponenten. Sie mögen die schnellen Seitenübergänge. Sie mögen es, Dinge auf einem Jamstack-kompatiblen Server zu hosten, mit all den schönen Entwickler-Vorschauen und so weiter. Sie mögen das Hot Module Reloading. Sie mögen Prettier und JSX. Sie mögen es einfach, und ich mache ihnen keinen Vorwurf. Wenn man eine solche Entwicklererfahrung genießt, ist es nicht gerade verlockend, zurück zum Authoring von PHP-Vorlagen zu gehen, bei denen man den Browser manuell aktualisieren muss und eine Art selbstgesteuerten Build-Prozess unterhält.
Frontity ist ein weiteres Produkt, das sich auf React + WordPress konzentriert. Geoff und Sarah haben letztes Jahr auf der Vue/Nuxt-Seite beschrieben, wie man all dies macht.
Aber wird Headless WordPress *populärer* werden als das traditionelle Theming-Modell von WordPress, das auf PHP-Vorlagen basiert, die einer expliziten Struktur folgen? Nein. Nun, vielleicht würde es das, wenn WordPress selbst die Idee fördert und Anleitungen, Schulungen und Dokumentationen anbietet, die es Entwicklern erleichtern, diesen Ansatz zu übernehmen. Ich würde mich dafür einsetzen, wenn WordPress sagen würde, dass eine headless Architektur der neue Kurs ist. Aber nichts davon ist wahr. Folglich ist es bis zu einem gewissen Grad eine Nischensache.
Wie nischig ist headless?
WP Engine ist ein großer WordPress-Hoster und hat ein ganzes System namens Atlas. Und diese Anstrengung sieht definitiv so aus, als würden sie diesen Nischenmarkt ernst nehmen. Ich bin mir nicht 100% sicher, was Atlas alles ist, aber es sieht aus wie ein Dashboard zum Erstellen von Websites mit interessant aussehendem Code-als-Konfiguration. Eines der Elefanten im Raum bei Headless WordPress ist, dass man nun *zwei* Websites verwalten muss. Man hat dort, wo man WordPress hostet und betreibt, und dort, wo man die Website hostet und betreibt, die die WordPress-APIs nutzt. Vielleicht bringt das diese beiden Dinge irgendwie zusammen. Das Bereitstellen von Git-Commits ist ansprechend und das, was ich heutzutage als Grundvoraussetzung für modernes Hosting betrachte.
Ein weiterer Grund, warum Leute an Headless WordPress interessiert sind, ist, dass das Endergebnis statisch sein kann, d. h. vorab generierte HTML-Seiten. Das bedeutet, dass der Server für Ihre Website stark durch CDNs abgedeckt werden kann, da es sich buchstäblich nur um statische Assets handelt, die sofort zum Download bereitstehen. Es gibt kein PHP oder eine Datenbank für serverseitiges Rendering, was langsam sein kann (und, um fair zu sein, behoben werden kann), da es einen Prozess vor dem Rendering hinzufügt.
Was ist „der WordPress-Weg“, um headless zu gehen?
Ich würde jeden Dienst, der eine statische Version Ihrer WordPress-Website erstellt, zum Headless-WordPress-Bereich zählen. Das liegt daran, dass diese Websites letztendlich WordPress-APIs verwenden, um diese statischen Dateien zu erstellen, genau wie Gatsby oder was auch immer sonst tun würde.
Das ist es, was Strattic tut. Sie stellen Ihnen eine WordPress-Website zur Verfügung, die sie als Staging betrachten. Sie erledigen Ihre WordPress-Arbeit dort und nutzen dann ihr Veröffentlichungssystem, um eine statische Version Ihrer Website in die Produktion zu verschieben. Das ist überzeugend, weil es etwas löst, was andere Headless-WordPress-Anwendungen nicht tun: *Dinge einfach auf die WordPress-Art zu erledigen*.
Zum Beispiel können benutzerdefinierte WordPress-Blöcke oder Plugins eine Ausgabe erzeugen, die nicht nur benutzerdefinierten HTML-Code, sondern auch CSS und JavaScript enthält. Stellen Sie sich einen „Karussell“-Block oder ein Plugin vor. Dieses Karussell funktioniert nicht, wenn Sie nur den Beitragstext aus einer API abrufen und auf eine Seite kopieren. Sie müssten entweder das CSS und JavaScript von woanders extrahieren und einbinden oder irgendwie wissen, dass dies nicht mehr die Art ist, wie man Dinge tut. Sie könnten die Bilder als Metadaten anhängen, sie clientseitig abrufen und Ihre eigene Implementierung eines Karussells vornehmen. Mit Strattic würde es theoretisch funktionieren, da HTML, CSS und JavaScript auf der statischen Website vorhanden sind. Aber bemerkenswerterweise haben Sie *kein* PHP, daher musste Strattic Formularintegrationen von Hand erstellen, sie verwenden clientseitiges Algolia für die Suche, Disqus für Kommentare usw., da keine serverseitige Sprache verfügbar ist.
Shifter ist ein weiterer Akteur in diesem Bereich. Es ähnelt Strattic, wo Sie in der WordPress-Administration an Ihrer Website arbeiten und dann eine statische Website veröffentlichen. Ich glaube, Shifter fährt Ihre WordPress-Website sogar herunter, wenn sie nicht in Gebrauch ist, was Sinn macht, da die Ausgabe statisch ist und es keinen Grund gibt, einen Server mit PHP und MySQL laufen zu lassen. Alternativ bietet Shifter ein reines Headless-WordPress-Setup, das vermutlich immer läuft, um externe API-Nutzung zu ermöglichen.
Es macht Spaß, über all das nachzudenken
Aber während ich darüber nachdenke, stelle ich fest, dass die Ideen und Diskussionen rund um Headless WordPress hauptsächlich auf den Entwickler ausgerichtet sind. WordPress hat diesen riesigen Markt von Leuten, die einfach keine Entwickler sind. Dennoch verwalten sie eine WordPress-Website und nutzen das Plugin- und Theme-Ökosystem. Das ist ziemlich cool, und es ist beeindruckend, dass WordPress beide Märkte so gut bedient. Es gibt einfach eine Menge mehr WordPress-Website-Besitzer, die keine Entwickler sind, als die, die es sind, vermute ich, daher allein wird Headless WordPress noch eine Weile nichts weiter als ein relativ nischiges Konzept bleiben. Aber, wissen Sie, wenn sie GraphQL in den Kern einbauen wollen, nehme ich es trotzdem gerne, danke.
Das ist eine großartige Darstellung des Themas.
Ich denke, eine interessante Diskussion wäre, wann Headless Sinn macht. Angesichts dessen, was WordPress ist, denke ich, dass der Fokus immer auf denen liegen sollte, die den Inhalt verwalten und erstellen. Headless macht das viel schwieriger.
Um es klar zu sagen, ich liebe Headless und wünschte, jedes neue WordPress-Theme, das ich erstelle, könnte headless sein. Es macht Spaß und es ist (einfacher) einen Workflow einzurichten und es ist
#dieZukunft. Melden Sie mich an.Aber wenn ich keine Website liefern kann, die für diejenigen, die täglich im Dashboard arbeiten, einfach und intuitiv ist, was bringt es dann?
Außerdem würde ich argumentieren, dass es schwierig ist, einen Webpack- oder Gulp-Build für eine nicht-headless Website einzurichten, als ein System zu schaffen, das sicherstellt, dass das headless Ergebnis konsistent mit dem übereinstimmt, was der Benutzer im Backend der Website erstellt?
Ich meine, vielleicht. Deshalb wäre eine Unterhaltung darüber, wann headless eine bessere Lösung als non-headless ist, interessant.
„die Ideen und Diskussionen rund um Headless WordPress sind hauptsächlich auf den Entwickler ausgerichtet“
Das bestreite ich. Die Bereitstellung von Markup ohne Bloat, ohne unnötige statische Ressourcen, ohne auch nur eine PHP-Engine ist schneller, sicherer und besser für Zugänglichkeit und SEO. Im Grunde ist es besser für Kunden und Benutzer.
Teufels Advokat
Eine saubere WordPress-Website, die von kompetenten Entwicklern mit aktuellem PHP erstellt wurde, zusammen mit einem optimierten Caching-System, kann sein
Schnell
Sicher
Zugänglich
Starkes SEO
Es ist nicht so, dass Sie Ihre Kunden/Benutzer benachteiligen, indem Sie sich *nicht* für Headless mit WordPress entscheiden.
hmm... Zumindest in meinem Land hat Headless WP nicht wirklich viel Einfluss.
Die meisten „Entwickler“ nutzen es nur, weil es so praktisch ist, ein Theme oder Plugin zu verwenden, das bereits von anderen Leuten erstellt wurde. Das Geschäftsmodell besteht einfach darin, niedriger abzurechnen und schneller zu liefern, weil man nicht viel für die eigentliche Entwicklung tun muss.
WordPress verliert zu viel Komfort, wenn es headless geht. Solange die Plugins keine Möglichkeit haben, headless zu unterstützen, denke ich, ist es schwer für headless WP, aus seiner Nische auszubrechen.
Toller Beitrag! Ich bin wirklich froh, dass Sie WP-Websites auf Strattic als headless eingestuft haben. Ich stimme natürlich zu, aber manche Leute denken, unser Ansatz sei nicht headless, weil die statische Website so bereitgestellt und gerendert wird. Aber meiner Meinung nach zählt das Endergebnis, und in unserem Fall ist die Live-Statik-Website tatsächlich headless.
Eines unserer Ziele bei Strattic ist es, die Welt des Headless auch für Nicht-Entwickler zugänglich zu machen. Derzeit ist ein Großteil des Ansatzes rund um Headless sehr entwicklerorientiert, was in Ordnung ist, aber die Leute ignoriert, die Websites täglich zur Verwaltung von Inhalten usw. nutzen. Mit Strattic sind sowohl Marketingexperten als auch Entwickler glücklich, da sie die Umgebungen erhalten, die sie wollen/brauchen.
(Übrigens, auf Strattic wird die WP-Website heruntergefahren, wenn sie nicht genutzt wird.)
Und ich stimme dem voll und ganz zu: „Auch die Idee, dass ich die WordPress API nicht nur zur Bereitstellung einer Website, sondern auch einer nativen Lese-App und einer digitalen, internetverbundenen Autobahnwerbetafel oder etwas Ähnlichem nutzen werde, ist keine Anwendungsfall, der an Popularität gewinnt, soweit ich das beurteilen kann.“
Ich sehe das immer wieder als Grund für die Verwendung von Headless und wie Sie sagten, gibt es nicht viele Anwendungsfälle für diese Art von Funktionalität. Selbst wenn eine WP-Website im Standardmodus läuft, verfügt sie immer noch über eine integrierte REST-API, mit der Inhalte an diese Werbetafel gesendet werden können.
Ich bin wirklich an Strattic interessiert, weil ich von dem Dienst noch nie gehört habe und er den Riss zwischen UX und DX adressiert.
Mit Headless muss man sich gewissermaßen entscheiden, worauf man sich konzentriert, und das ist ein wirklich intelligenter Ansatz zur Lösung des Problems.
Schön, dass Ihnen unser Ansatz gefällt, Jamie!
In unserem Unternehmen planen wir, headless zu gehen. Unsere Website läuft seit 1,5 Jahren mit Elementor und das war großartig in Bezug auf schnelle Anpassungen und Experimente mit unseren Lesern. Der größte Nachteil ist die Seitengeschwindigkeit und der Umfang, den Elementor mit sich bringt. Unsere Idee ist es, SvelteKit zu verwenden und Teile der Website langsam in serverseitig gerenderte Websites von SvelteKit zu überführen. Wir planen, den Speicherort für den Nginx-Proxy zu überschreiben, um den Übergang langsam Seite für Seite und Taxonomie für Taxonomie zu testen, ohne monatelang zu arbeiten und einen kompletten Relaunch auf einmal durchzuführen :)
Unser größtes Problem im Moment ist, dass die Permalinks nur aus dem Post-Slug bestehen, daher können wir nicht alle einzelnen Posts gleichzeitig ansprechen...
Wir haben viele Elementor-Websites, die auf Strattic laufen, um genau die Probleme zu lösen, die Sie beschreiben. Zum Beispiel, hier ist eine Fallstudie über ein Unternehmen, das seine Elementor-Website zu Strattic migriert hat und 50% schneller wurde: https://www.strattic.com/coralogix-got-50-faster-on-strattic-without-an-extra-line-of-code/
Wir haben eine kostenlose Testversion, damit Sie eine Kopie Ihrer Website zu Strattic migrieren, eine statische Version veröffentlichen und die Geschwindigkeit mit Ihrer aktuellen Website vergleichen können.
Hallo Miriam Schwab, danke für Ihren Kommentar!
Wir verwenden derzeit w3t total cache mit unserer eigenen Redis-Instanz (sowohl WordPress als auch Redis laufen auf demselben VPS). Die TTFB beträgt bereits etwa 60-90 ms anstelle von 1-2 Sekunden (wenn angemeldet). Die größten Probleme für unsere Seite sind derzeit die Lighthouse-Ergebnisse, die sich aus Elementor ergeben. Der Jamstack-Weg ist daher ziemlich unvermeidlich...
Vielen Dank für den tollen Beitrag!
Eine Korrektur
Gatsbys
gatsby-source-wordpressPlugin verwendet nicht die WordPress REST API. Das galt für frühere Versionen dieses Quell-Plugins, aber die aktuelle Version verwendet ausschließlich WPGraphQL, um Daten von WordPress zu beziehen.Ich stimme Ihnen zu, @KellenMace.
Währenddessen wurde das Plugin komplett überarbeitet, um die Glaubwürdigkeit von headless WordPress zu verbessern!
Ich stimme zu, dass das Abrufen von WordPress JSON-Daten in native Apps/elektronische Werbetafeln/etc. wahrscheinlich nicht sehr verbreitet ist. Es gibt jedoch einen weiteren Anwendungsfall, der meiner Meinung nach eine Überlegung wert ist –
Ich habe mit Unternehmen zusammengearbeitet, die Daten aus WordPress, Salesforce, Shopify und anderen APIs abrufen möchten, und dann all diese Daten verwenden, um die HTML-Seiten zu erstellen, die letztendlich an die Benutzer geliefert werden. Das nennt Gatsby den „Content Mesh“.
Um dies im traditionellen WordPress zu tun, müssten Sie diese Drittanbieter-Dienste vom WordPress-Server aus anpingen, die Antwortdaten zwischenspeichern, benutzerdefinierten Code schreiben, um den Cache zu leeren und diese Daten regelmäßig neu zu generieren usw.
Mit einem Headless-Ansatz ist das Abrufen von Daten aus mehreren APIs wie diesem einfacher zu verwalten. Und mit Funktionen wie inkrementeller statischer Generierung in Next.js müssen Endbenutzer nie darauf warten, dass veraltete Cache-Daten neu generiert werden – das geschieht asynchron auf periodischer Basis, um die Daten frisch zu halten.
Dies ist sicherlich nicht anwendbar auf Websites, die nur WordPress-Daten verwenden. Für diejenigen, die Daten aus mehreren externen Diensten beziehen müssen, kann es jedoch eine UX-Verbesserung bieten.
Es ist schade, dass nicht etwas mehr Recherche in diesen Beitrag geflossen ist, ich denke, es ist sehr wichtig, dem Leser mitzuteilen, was der betreffende Dienst tut, anstatt zu raten…
Davon abgesehen betreiben wir einen verwalteten Headless-Host und unsere Hauptkundschaft sind diejenigen, die WordPress-Blogs auf ihren Shopify-Shops haben möchten. Das ist ein riesiges Publikum. Unser Ziel ist es auch, Nicht-WP-Entwickler anzusprechen und uns auf JavaScript-Entwickler zu konzentrieren, um ihren Kunden das beste CMS zu bieten, ohne WP kennen zu müssen.
Die Leute sehen WordPress oft als Website-Builder. In erster Linie ist WordPress ein großartiges System für Blogs. Mit den neuen headless Plugins können wir dieses gut durchdachte System jetzt auslagern, ohne WordPress als Frontend zu nutzen.
Sie haben ein perfektes Beispiel gegeben: WordPress als CMS in einem E-Commerce-System. Sie vereinen zwei Welten.
Es besteht kein Zweifel, dass es einen Trend hin zu Headless und Cloud gibt. Öfter folgen viele Entwickler nur dem Hype-Faktor.
Verstehen Sie mich nicht falsch, ich liebe Headless, ich programmiere lieber in JS als in PHP und bin mehr als glücklich, mit View.js, Serverless und ähnlichem voll einzusteigen.
Dennoch braucht man manchmal nur eine Website, die Inhalte anzeigt, vielleicht Bestellungen entgegennimmt. Und native WordPress ist dafür gut geeignet.
Wie im Artikel CSS Tricks ist eine WordPress-Poster-Website erklärt, ist WordPress mit benutzerdefiniertem Themengestaltung/Programmierung oft die perfekte Antwort auf die gestellte Aufgabe.
Wie viele externe Dienste (die Ihre Inhalte verstreuen) und Klebstoff-Code müssten Sie zur Verwaltung von Inhaltsseiten, Blog-Posts, einem Forum und einem E-Commerce-System aufrechterhalten?
WP erledigt all das fast out of the box. Sie müssen nur ein paar benutzerdefinierte Vorlagen und CSS hinzufügen, hier und da ein wenig Logik bearbeiten, falls erforderlich, und das war's.
Schauen Sie einfach, was die Leute tun: Sie hosten ihren Shop auf Shopify und landen am Ende trotzdem, einen WordPress für ihren Blog bereitzustellen.
WP ist weit davon entfernt, immer die Antwort zu sein, aber wenn ich headless gehe, dann bedeutet das, dass ich wahrscheinlich ein anderes Backend finden sollte.
Ich habe meinen WP-Blog auf headless mit React umgestellt, und zwar ziemlich genau aus dem von Ihnen genannten Grund – ich mag React. Eigentlich war es, als ich React letztes Jahr während des Lockdowns lernte (ich weiß, ich bin spät dran), und ich wollte an einem realen Projekt arbeiten. Ich bin mit dem Ergebnis zufrieden, und mein nächster Schritt ist, es mit NextJS neu zu schreiben.