WordPress als Headless CMS – Überblick & Beispiel mit Vue.js

Zuletzt aktualisiert:

WordPress, WordPress, überall WordPress. Das beliebte Content Management System macht gut ein Drittel des gesamten Internets aus. Klassische WordPress Entwicklung bietet zweifelsohne viele Vorzüge für eine Fülle von Anwendungsfällen. Mit der REST API besteht jedoch auch die Möglichkeit WordPress nur als Backend zu verwenden und mit einer modernen Frontend Technologie wie React oder Vue.js zu kombinieren. Das nennt man dann WordPress Headless. 

Es ist natürlich verführerisch, dass beinahe jeder ohne große Vorkenntnisse innerhalb weniger Minuten eine Website inklusive Backend mit CMS und Datenbankanbindung ans Laufen bringen kann. 

Schön wäre es doch, wenn man die Vorzüge dieses “Backends für Jedermann” mit einem modernen Frontend Framework wie z.B. Vue.js kombinieren könnte. Und genau da kommt Headless WordPress ins Spiel.

Was ist ein “Headless” CMS bzw. Headless WordPress?

Bei “Headless WordPress” wird lediglich das Backend von WordPress verwendet. Das WordPress Entwickler Team geht mit der Zeit und hat ab WordPress Version 4.7.0 eine REST API spendiert, über welche auf die Inhalte der WP Datenbank zugegriffen werden kann. Diese ist ziemlich flink und kann vollständig und sehr einfach gecached werden. Somit hat jede WordPress Installation automatisch einen Zugriffspunkt, über welchen Apps und Websites Inhalte als JSON Daten abrufen können. 

Vorteile von WordPress Headless (vs. WordPress)

  • Webentwickler können sich mehr oder weniger auf Knopfdruck ein einfaches Backend erstellen
  • Benutzer können Inhalte über das gewohnte WordPress Backend pflegen
  • Moderne Frontend Frameworks ermöglichen aufwendige Websites und gute UX
  • Webdesigner haben noch mehr Möglichkeiten und können mit Transitions zwischen den URLs arbeiten
  • Dadurch gibt es mehr gestalterische Freiräume, Interaktivität und Animierbarkeit

Nachteile von Headless WordPress (vs. WordPress)

  • Plugins die das Frontend betreffen sind nicht nutzbar
  • Individuelle Programmierung erforderlich, keine Verwendung von fertigen Themes möglich
  • Frontends sind aufwendiger und Anpassungen können nur über Entwickler gemacht werden, nicht auf User Ebene
  • Für Single Page Applicationss (SPAs) sind zusätzliche Kenntnisse erforderlich (Frontend Frameworks, NPM, Webpack…)
  • Es ist sehr aufwendig eine Single Page Application SEO-mäßig gut aufzubereiten. Eine SEO Agentur wird Ihnen wahrscheinlich eher zu klassischem WordPress raten.
  • In manchen Fällen ist Server Side Caching notwendig (z.B. mit Nuxt.js). Damit sind einige der genannten Vorteile wieder hinfällig.

Wann macht  WP Headless Sinn

Die Frage ob und wann die Verwendung von Headless WordPress Sinn macht, kann ich mir aus zwei Ausgangssituationen stellen:

  1. Ich will eine Single Page Application erstellen und brauche ein einfaches Backend
  2. Ich will auf jeden Fall WordPress verwenden

Bei der ersten Ausgangssituation gilt es zu beleuchten, ob ich mit Hilfe von WordPress die Funktionen im Backend realisieren kann, die ich für meine SPA brauche. Im Endeffekt taugt dies hauptsächlich um statische Daten zur Verfügung zu stellen, die bequem über das WP CMS gepflegt werden können.

Bei der zweiten Variante geht es letztendlich um die Abwägung der Vor- und Nachteile einer SPA gegenüber einer normalen WordPress Installation. Diese hatte ich weiter oben aufgelistet.

Auch wenn das natürlich immer von der jeweiligen Umsetzung anhängt kann man grob festhalten, dass SPAs nach erstmaligem Laden performanter und “lebendiger” umgesetzt werden können und eine bessere User Experience bieten können (z.B. gibt es keinen Break bei einem URL Wechsel). 

Wenn es um eine schicke, schnelle und interaktive Seite geht, kann eine normale WP Installation einer SPA nicht das Wasser reichen. Bei der Kombination mit Headless WordPress lässt sich eine SPA in vielen Anwendungsfällen sehr bequem im Backend pflegen. Wenn es im Frontend richtig gut werden soll, stößt einfaches WordPress schnell an seine Grenze.

Aber letztendlich hat alles seinen Platz. Schließlich liegt der Ursprung von WordPress ja gerade darin, dass jeder der sich etwas damit beschäftigt eine Website erstellen kann. Der lokale Sportverein wird sicher nicht sein Jahresbudget für eine neue Seite ausgeben wollen. In solchen Fällen bietet WordPress eine solide Grundlage!

Aber auch im professionellen Umfeld wird WordPress häufig verwendet. Meiner Meinung nach ist es gerade bei Contentlastigen Seiten wie Blogs und Magazinen nach wie vor Mittel der Wahl.Ein SEO Projekt würde ich immer mit „normalem“ WordPress umsetzen! Zudem bietet es unendlich viele Plug-Ins und Integrationen für alle Einsatzgebiete “von der Stange”. Benötigt man z.B. einen Buchungskalender, so lässt sich das mit einem Plug-In in kürzester Zeit lösen und das für einen Bruchteil der Kosten die bei eine SPA entstanden wären. Ein beschränktes Budget in Verbindung mit aufwendigen Funktionen schließen die Programmierung einer Single Page Application in jedem Fall aus.

Verbindung zur WordPress REST API herstellen

Wer mit der REST API arbeiten möchte, sollte sich zuallererst mit JSON Daten vertraut machen. Denn genau diese liefert diese aus, wenn ein entsprechender GET  Http Request gestellt wird. Und zwar grundsätzlich bei jeder WordPress Webseite. Es sei denn die REST API wurde aktiv deaktiviert. 

Fügt man im Browser die Endung ‘wp-json/wp/v2/posts?’ zur URL eine beliebigen WP Installation hinzu, bekommt man als Antwort alle Posts im JSON Format in den Browser geschrieben. 

Um mit der REST API rumzuexperimentieren und sich einen Überblick über die Endpunkte zu verschaffen, sollte man anstatt eines Browser jedoch lieber das Tool Postman verwenden, welches neben besserer Übersicht z.B. auch die Response Header anzeigt und andere Requests außer GET ermöglicht.

GET Request mit Vue.js

In Vue.js verwendet man am besten Axios um https-Requests an die REST API zu senden. Folgender GET Request würde unter Verwendung des “created” Lifecycle-Hooks die kompletten JSON Daten zu den neuesten 10 Posts in die Variable posts schreiben (posts muss dazu vorher unter “data” als Array definiert werden:

created () {
        axios.get('https://meine-website.de/wp-json/wp/v2/posts?' )
        .then(res => {  
		this.posts = res.data
        }
}

Im Template Bereich könnte dann die Überschrift des ersten Posts wie folgt ausgegeben werden:

{{ posts[0].title.rendered }}

POST Request mit Vue.js

Ein Post Request lässt sich mit Axios ebenso leicht realisieren:

methods: {
	postData: function(data) {
		const session_url = "https://meine-seite.de/wp-json/wp/v2/posts"

            axios.post(session_url, data, {
                auth: {
                    username: 'user',
                    password: 'anwendungspasswort'
                }
            }).then( res => {
                alert('Übertragung abgeschlossen')
            });
}	

Die Daten müssen natürlich im entsprechenden Format zur Verfügung gestellt werden.

WordPress Headless Fallstricke im wahren Leben

Caching und Cross Origin Requests (CORS)

Eingangs habe ich das Caching noch als großen Vorteil genannt. Was die Serverantwortzeit betrifft ist das auch der Fall. Es gibt jedoch Grenzfälle wo Caching bei Headless WordPress problematisch sein kann. Nämlich dann, wenn die Anfragende Single Page Application oder sonstige zugreifende App auf einem anderen Server liegt als die WordPress Installation UND mehr als eine APP auf die REST API zugreifen soll. Das ist dann nämlich ein sogenannter Cross Origin Request (CORS), also eine Anfrage von einer anderen “Herkunft”. 

Aus Sicherheitsgründen blockieren moderne Browser CORS, wenn im Header der Server-Antwort die anfragende URL nicht mit “Access-Control-Allow-Origin” benannt wird. Das ist erstmal kein Problem, den den Response Header kann man leicht entsprechend anpassen. Dazu sind lediglich ein paar Zeilen Code in der functions.php oder einem Plugin erforderlich. Das könnte z.B. so aussehen:

function cors( $value) {
     $origin_url = 'http://localhost:8080';
     header( 'Access-Control-Allow-Origin: ' . $origin_url );
     header( 'Access-Control-Allow-Methods: GET' );
     header( 'Access-Control-Allow-Credentials: true' );
     return $value;
}
add_action( 'rest_api_init', function() {
     remove_filter( 'rest_pre_serve_request', 'rest_send_cors_headers' );
     add_filter( 'rest_pre_serve_request', 'cors');
}, 15 );

Somit wären Anfragen der URL localhost:8080 möglich. Was aber, wenn noch weitere Domain die Erlaubnis bekommen sollen? WordPress macht auch das erstmal möglich. Dazu muss nur die anfragende URL über die Funktion get_http_origin() identifiziert und mit einer Liste aller erlaubten Origins verglichen werden (die man entsprechend definiert). Ist die anfragende Origin enthalten, lasse ich sie per PHP in den Header schreiben. Folgend erlaube ich noch zusätzlich localhost:3000 als Origin:

function cors( $value) {
     $origin = get_http_origin();
     $allowed_origins = [ 'http://localhost:8080', 'http://localhost:3000'' ];
     if ( $origin && in_array( $origin, $allowed_origins ) ) {
          header( 'Access-Control-Allow-Origin: ' . esc_url_raw( $origin ) );
          header( 'Access-Control-Allow-Methods: GET' );
          header( 'Access-Control-Allow-Credentials: true' );
     } 
     return $value;
}

Doch jetzt gibt es einen Unterschied! Bei der ersten Variante gibt es nur einen einzigen möglichen Header. Das bedeutet, dass Script muss nur einmal ausgeführt werden und das Ergebnis kann getrost im Cache abgelegt und bei jeder Anfrage ausgeliefert werden. 

Beim zweiten Fall muss der Header aber dynamisch an die anfragende (erlaubte) Origin angepasst werden. Wird nun aus dem Cache ausgeliefert, wird immer nur eine Origin Domain funktionieren (diejenige die zuerst angefragt hat).

Indem die REST API nicht gecached wird, lässt sich das vermeiden, was natürlich Einbußen in der Geschwindigkeit mitbringt. Eine Lösung wäre unter Umständen verschiedene Apps zu verschiedenen Endpunkten (ggf. Custom Endpoints) zu schicken. 

HTML Render-Funktion

Ein weiteres (kleines) Problem liegt darin, dass der gerenderte Content von WordPress Posts und Pages, welcher über die REST API geholt wird nicht einfach als String ausgegeben werden kann. Dieser enthält nämlich alle escaped HTML Tags, statt die Tags zu rendern.

Zum Glück liefert Vue.js die Lösung für dieses Problemchen mit und man braucht den String nicht mühselig umzubauen. Es kann einfach in einen HTML-Tag v-html=’meinContentString’ eingefügt werden. Dann werden alle Tags aus dem String als HTML gerendert.

Authentifizierung

Bei Requests außer GET ist an der REST API eine Authentifizierung nötig. Die wenig elegante aber sehr einfache Lösung dazu wäre die User Daten eines Users mit Schreibrechten als Basic Auth mit dem Request zu schicken:

auth: {
       username: 'user',
       password: 'passwort'
}

Würde es einem Bösewicht gelingen dies anzufangen, könnte er sich in unser WordPress Backend einloggen und dort alles machen, was der User mit entsprechenden Rechten darf. 

Eine ebenfalls sehr einfache aber etwas sichere Lösung bietet sich seit WordPress Version 5.7. Seitdem ist es möglich, separate Anwendungspasswörter für die REST API zu erzeugen. Diese können per Knopfdruck vom Administrator widerrufen werden und erlauben nur den Zugang über die REST API, kein einloggen als User. Erstellt werden können diese über das Nutzerprofil eines Administrators.

Richtig sicher bekommt man eine direkte Anfrage die vom Browser direkt an die REST API geht jedoch meines Wissens nicht (Kommentare dazu sind herzlich willkommen). Das bezieht sich natürlich nur auf schreibende Zugriffe.

Häufig gestellte Fragen

Was ist ein Headless Content Management System (CMS)

Bei einem Headless Content Management System sind Frontend und CMS vollständig voneinander getrennt. Dadurch kann das Frontend (Website oder App) mit einer beliebigen Technologie gestaltet werden. Auf das CMS wird über http-Requests zugegriffen und die Inhalte per API bereitgestellt. So können ggf. auch mehrere Webseiten und Apps (z.B. Mobile und Web) auf die Daten aus dem selben CMS zurückgreifen.

Was ist WordPress Headless?

Bei WordPress als Headless CMS wird das Frontend von WordPress nicht verwendet. Es wird lediglich das Backend und die Datenbank zur Pflege von Daten und Inhalten genutzt. Durch die standardmäßig vorhandene REST API von WordPress kann jede Webseite und App auf eine WordPress Installation die online ist zugreifen und sich an den API Endpunkten Daten per http-Request lesen und schreiben.

Warum nutzt man WordPress Headless?

Beim der Headless Nutzung wird auf WordPress nur über die REST API zugegriffen und es wird kein WordPress Frontend erzeugt. Man kann so z.B. verschiedene Apps gleichzeitig mit dem WordPress Backend pflegen (z.B. eine mobile App und eine Web-App).

Ein Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nehmen Sie Kontakt auf!

EINGENETZT B2B SEO & Webentwicklung

Im Kaiserviertel
Bismarckstraße 54
44135 Dortmund

0231 - 1370 7678
info@eingenetzt.net

Nutzen Sie auch die Kontakt-Buttons unten rechts!