Month: October 2016

Ist diese REST API auch was für mich?

FrontKit

In den letzten Jahren ist ja viel über die WordPress REST API geschrieben und spekuliert worden. Das sie fantastisch sei und sich mit ihr alles ändern könne. Zugleich scheint das Thema aber sehr weit weg zu sein von der eigentlichen WordPress Endanwenderin. Auch wenn die REST API mit 4.7 in den Core kommt wird man sich nach wie vor über wp-login.php einloggen, auf das Dashboard gelangen und seine Artikel wie gewohnt schreiben. Obwohl die API im Core ist wird sich für die Endanwenderin erstmal nicht viel geändert haben und zu Recht kann man sich die Frage stellen: Wozu der ganze Hype?

Die REST API ist derzeit vor allem eines: Eine Spielwiese für WordPress Entwicklerinnen. Wenn diese Euch dann begeistert über die API erzählen, dann kriegt Ihr häufig irgendwann kryptische Texte zu lesen und mit leuchtenden Augen berichten wir dann, dass das jetzt die REST API sei.

So sieht also die REST API aus?
So sieht also die REST API aus?

Gerne wird dann, ob der neuen Möglichkeiten, mit hübschen Schlagwörtern um sich geschmissen wie “Decoupled themes“, “Headless CMS“, neue “SAAS”-Modelle und vielleicht am eingängigsten noch “Mobile Apps”, da haben wir dann doch alle schonmal irgendwie drauf gedrückt, auf so eine App, ist aber dann doch etwas unspezifisch. Die Wahrheit ist, dass doch alles noch etwas wolkig daher kommt, so in der Form: Mit der REST API könnte man.

Eine kleine Demo

Also ist dieses REST API jetzt etwas für mich? In diesem kleinen Screencast möchte ich ein Plugin vorführen, welches ich für eine gelungene Anwendung auf Grundlage der REST API halte: Das “FrontKit for WordPress” – ein neuer Frontend Editor.

Wie ich auch schon im Screencast erwähnt habe, ist das Plugin derzeit im Alpha Stadium. In meinen Tests lief es aber wunderbar mit WordPress Twenty Sixteen. Von Hause aus unterstützt das Plugin die offizielle Twenty-Reihe von dreizehn bis 16 und ich denke einmal, dass Twentyseventeen, sobald es erscheint, auch unterstützt werden wird.

Wenn Ihr jedoch keines der offiziellen Themes verwendest, so funktioniert das Plugin erst einmal nicht, denn es weiß nicht, wo es den Inhalt und den Titel eines Blogbeitrags im HTML Code finden kann. Deshalb müsst Ihr in der functions.php Eures Child Themes erklären, dass das Theme FrontKit unterstützt und wo in der HTML-Ausgabe es den Titel und den Inhalt findet.

Sagen wir, Euer Titel ist immer von <h1 class="entry-title"> umschlossen und der Inhalt von einem <div class="entry-content">, so könnte die Unterstützung von FrontKit durch das Theme folgendermaßen deklariert werden:

.single-post sollte dabei im <body>-Tag durch die Funktion body_class() automatisch eingefügt werden.

FrontKit ist nur eines von vielen Beispielen, wie die REST API, welche ab Dezember in WordPress enthalten sein wird, in Zukunft die Arbeit mit WordPress erleichtern und verschönern könnten.

Was denkt Ihr? Habt Ihr andere Beispiele oder vielleicht selbst schon eine Idee, wie Ihr die REST API einsetzen möchtet?

(Private) Metadaten in der REST API

Ich hatte ja schon vor einiger Zeit einen Beitrag verfasst, dass im Zuge der REST API die Funktion register_meta() neue Bedeutung erlangt. Mittlerweile hat sich einiges getan. Nicht nur, dass die API mit 4.7 in den Core kommen soll 🎉: Die WordPress REST API kann nun auch Metadaten ausgeben und authentifizierte Nutzer können Metadaten ändern.

Sagen wir, das Postmetafeld foo soll über die API zugänglich gemacht werden. Dazu muss man foo nun zunächst über register_meta() registrieren. Im ersten Parameter übergibt man, um welchen Typen von Metadatum es sich handelt: Für Metadaten, welche an Seiten oder Beiträge angehängt werden, übergibt man post. Für Usermetadaten user und für Termmetadaten term. Der zweite Parameter enthält die Bezeichnung des Datums, in unserem Fall wäre dies foo und schließlich übergibt man einen Argumentenarray:

  • show_in_rest
    ist ein Boolean. Setzt man ihn auf true wird das Metafeld an die API übergeben.
  • type
    gibt den Typen an. Also beispielsweise, ob es sich um einen string oder um einen integer handelt.
  • description
    dient dazu, eine Beschreibung zu hinterlegen, welche das Feld beschreibt und auch über die API ausgegeben wird.
  • auth_callback
    enthält den bereits aus der ursprünglichen Version von register_meta() bekannten Authentifizierungs Callback.
  • sanitize_callback
    enthält den bereits aus der ursprünglichen Version von register_meta() bekannten Reinigungs Callback, welcher aufgerufen wird, um das Datum vor dem Speichern zu reinigen.
  • single
    gibt an, ob dieses Datum nur ein einziges Mal gespeichert werden kann, oder ob es mehrere Einträge unter dem selben Schlüssel geben kann. Dies entspricht dem single-Boolean in get_post_meta().

Um nun foo über die API bereitzustellen, genügt es schon, den Schlüssel wie folgt zu registrieren:

register_meta( 'post', 'foo', array(
	'show_in_rest' => true,
));

Die Ausgabe in der API sähe dann wie folgt aus:

Ein Metafeld in der Rest API Ausgabe
Ein Metafeld in der Rest API Ausgabe

Da wir das Feld nicht als single ausgewiesen haben, wird es als Array ausgegeben. mit single true würde nur der String zurückgegeben.

Mehr Informationen zur REST API und zu spezifischen Befehlen der REST API finden sich auf wp-api.org.

Private Metafelder

In unserem Gespräch über die REST API auf dem WP Sofa hatte Felix Arntz die Frage aufgeworfen, ob es möglich wäre, Metafelder auch so zu registrieren, dass nur authentifizierte Nutzer die Möglichkeit hätten, diese einzusehen. Man denke beispielsweise an eine App, welche einen Blick auf den tagesaktuellen Umsatz von Produkten wirft. Das wären keine Daten, die man öffentlich zugänglich machen wollte.

register_meta() bietet von sich aus dazu zunächst keine Optionen an, weshalb ich das im Gespräch zunächst verneinte. Doch es wäre ja tatsächlich eine interessante Erweiterung und etwas Schade, wenn das nicht ginge. Heute hatte ich etwas Gelegenheit noch einmal darüber nachzudenken und kam zu dem Schluss, dass register_meta() eine solche Unterscheidung auch gar nicht braucht, weil wir diese während des Registrierungsprozesses selbstverständlich selber treffen können.

Was ich meine: Ein authentifizierter Aufruf in der API ist letztlich ein eingeloggter Benutzer und sämtliche Funktionen wie current_user_can() funktionieren.

Wenn wir also bestimmte Felder über die API nur bestimmten Nutzern zugänglich machen wollen, so können wir dies schon jetzt aufgrund der Art und Weise, wie ein authentifizierter Aufruf in WordPress funktioniert:

add_action( 'rest_api_init', function() {
	if ( ! current_user_can( 'edit_posts' ) ) {
		return;
	}

	register_meta( 'post', 'foo', array(
		'show_in_rest' => true,
	));
});