Tag: rest-api

Nonces in der REST API

Wenn Du einfach mal schnell ein Nonce in der REST API von WordPress validieren möchtest kann es passieren, dass Du auf ein kleines Hindernis stößt. Ich hatte letztens ein kleines Script geschrieben, welches entweder über die admin-ajax.php läuft, wenn die REST API nicht vorhanden ist, ober aber über die REST API.

Schauen wir uns folgendes Script an, um das folgende Problem zu verdeutlichen:

Wir registrieren also die Ajax Action für admin-ajax.php und eine neue Rest Route. Der Callback ajax_nonce_test() bereitet im Wesentlichen die Daten auf und führt dann auf nonce_test(), die Funktion, welche auch von der Rest Route /rest-api-nonces/v1/nonce-test aufgerufen wird.

Am Ende registrieren wir noch einen Shortcode, der uns nur schnell die Test-URLs ausgibt.

Soweit der Überblick. Zentral ist nun, was in nonce_test() passiert. Hier wird geprüft, ob das in $request['testnonce'] übergebene Nonce gültig ist. Wenn nicht wird “FALSE” zurückgegeben, oder aber “TRUE”.

Jetzt zum Witz. Loggen wir uns ein, gehen auf die Seite und rufen die admin-ajax.php auf, so werden wir "TRUE" erhalten, über die REST API "FALSE". Whaaaat? Mehrere Sachen sollten hier beachtet werden:

  1. Die REST-API authentifiziert eine⋅n Benutzer⋅in anders als die admin-ajax.php.
  2. Um ein Nonce zu erstellen und zu verifizieren wird die User-ID herangezogen.

Ob ein⋅e Benutzer⋅in eingeloggt ist oder nicht, darüber entscheidet ein Cookie, welcher beim Einloggen hinterlegt wird. Passt der Cookie, sind wir eingeloggt. Geht die Nutzer⋅in auf die admin-ajax.php so ist er oder sie eingeloggt. Die REST API allerdings verwendet eine etwas umfangreichere Cookie-Authentifizierung. Hier genügt nicht ein einfaches Cookie, sondern dieses muss zusammen mit einem – Ironie der Geschichte – gültigen Nonce übergeben werden.

Basics der Authentifizierung in der REST API

In der WP_REST_Server gibt es eine check_authentication Methode, die eigentlich nur aus dem Filter rest_authentication_errors besteht. Wird über diesen Filter ein WP_Error-Objekt übergeben gilt eine Authentifizierung als gescheitert und wir erhalten ein “Du bist nicht berechtigt”-Response zurück. Über diesen Filter können also User-Authentifizierungen stattfinden.

Von Haus aus bringt WordPress die sogenannte “Cookie-Authentifizierung” mit, welche in der rest_cookie_check_errors() stattfindet. Wenn der Prozess in diese Funktion rennt sind wir noch immer – über unseren Cookie – eingeloggt. Doch wenn das entsprechende Nonce nicht gefunden wird, werden wir zunächst ausgeloggt, bevor es – jetzt eben nicht mehr eingeloggt – weiter geht. Wird ein Nonce gefunden, welches allerdings den falschen Wert enthält, so wird ein WP_Error zurückgegeben und der Zugriff ganz geblockt.

Wenn wir also mit dem Codesnippet von oben schließlich in unserem nonce_test()-Callback ankommen, haben wir keine User-ID mehr, die es allerdings braucht, da das Nonce mit einer solchen ID erstellt wurde.

Wie funktioniert Cookie Authentifizierung in der REST API?

Statt also irgendwie willkürlich ein Nonce zu übergeben, welches dann im Callback geprüft wird (es mag Gründe dafür geben, aber in meinem Fall brauchte ich es nicht noch einmal), sollte also ein spezielles Nonce übergeben werden: wp_create_nonce( 'wp_rest' );. Und natürlich muss auch der Parameter stimmen. Das wp_rest Nonce kann entweder über den Parameter _wpnonce oder aber über den Request Header X-WP-Nonce. übergeben werden. Eine gute Einführung dazu findest Du auf der API Dokumentation.

Zurück zu meinem Beispiel

Für meine Zwecke genügte es also, über den _wpnonce Parameter zu gehen. Da das Nonce in der REST API automatisch schon geprüft wird, verschiebe ich die Nonce-Validierung in die Ajax-Funktion. So sieht mein überarbeiteter Code aus:

Fazit

Wenn Du also irgendwo in Deinem Rest API Callback Nonces brauchst, achte darauf dass der Loginstatus der Nutzer⋅innen mit dem im Frontend überein stimmt. Vermutlich erledigt sich damit auch schon die Notwendigkeit für Dich, ein Nonce überhaupt zu benutzen, aber es mag Umstände geben, in denen es Sinn machen kann, auch im Callback Nonces zu validieren.

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,
	));
});

So schaltest Du die WordPress REST API ab.

Die Entwicklung der WordPress REST API ist sicherlich eine der spannendsten Entwicklungen in der derzeitigen WordPress Entwicklung. Sie ermöglicht eine einfach zu erweiternde Schnittstelle für die Kommunikation mit anderen Programmen. Bisher ist im WordPress Core nur die sogenannte “Infrastruktur” vorhanden, auf welche unter anderem die oEmbeds aufsetzen (welche ich an anderer Stelle ausführlich behandelt habe).

Mit Hilfe der Infrastruktur ist es für Entwickler sehr leicht möglich, eigene sogenannte Endpoints zu registrieren. Über diese können dann andere Programme mit dem WordPress system interagieren und nach festgelegten Parametern Informationen ein- oder auslesen. Solche Endpoints sind unter anderem für Plugins interessant, welche Ajax-Anfragen an das System stellen möchten.

Derzeit wird an WordPress spezifischen Endpunkten gearbeitet, welche (irgendwann einmal) ebenfalls über die REST API im Core verfügbar sein sollen. Derzeit kann man sich diese Endpunkte als eigenes Plugin separat installieren.

Wenn man allerdings eine Webseite betreibt, welche die REST API nicht weiter nutzt und diesen Datenkanal lieber schließen möchte, so hilft dabei ein einfaches kleines Snippet, welches man sich in die functions.php des Child Themes packen kann.

Normalerweise erreicht man die REST API über die URL http://meine-seite.de/wp-json/. Dahinter verbirgt sich sozusagen der Ausgangspunkt in die API. Da die API allerdings auch im WordPress Backend mehr und mehr benötigt wird, sollte man die REST API so abstellen, dass eingeloggte Benutzer sie weiterhin verwenden können. Ansonsten würden Funktionen des Admins nicht mehr laufen:

Diesen Ausgangspunkt schreibt die WordPress REST API allerdings auch in den HTML-Quellcode, damit andere Programme diesen finden können. Mit Hilfe des folgenden Befehls kann man dies unterdrücken:

remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );

Da diese Information auch über den Header mit gesandt wird, empfiehlt es sich auch, diese Information nicht zu schicken:

remove_action( 'template_redirect', 'rest_output_link_header', 11 );

Der Vollständigkeit halber kann man diese Information dann auch aus der XMLRPC API (Ja, WordPress verfügt auch über eine XMLRPC-Schnittstelle!) entfernen:
remove_action( 'xmlrpc_rsd_apis', 'rest_output_rsd' );

Mit diesen vier Zeilen kannst Du also die WordPress REST API schnell und einfach deaktivieren, falls Du diese auf Deiner Seite nicht möchtest.

Was passiert mit register_meta?

Edit: Dies ist ein veralteter Artikel. Auf wordpress.org findet sich eine Übersicht über die Änderungen in register_meta.


Metadaten, also benutzerdefinierte Felder, sind ein zentrales Konzept für die WordPress-Entwicklung. Erst dieses Konzept ermöglicht es, zu Beiträgen, Seiten, Terms, Kommentaren, benutzerdefinierten Posttypes und Benutzern zusätzliche Daten zu hinterlegen und damit eine ganz neue Komplexitätsstufe zu erreichen, welche WordPress über das Niveau eines Blogsystems hinaustreibt. Um so erstaunlicher ist es eigentlich, dass eine Funktion wie register_meta(), von der man ja dem Namen nach annehmen würde sie sei von zentraler Bedeutung, eher ein Nischendasein führt. Man würde ja erst einmal annehmen es sei notwendig Metadaten zu registrieren, wenn es eine solche Funktion gibt, doch das muss man gar nicht und so bleibt diese Funktion meistens unbeachtet.

Nun allerdings scheint Bewegung in die Sache zu kommen. In diesem Beitrag möchte ich mich mit den Neuerungen beschäftigen und in wie fern diese die Funktion für WordPress Entwickler interessant macht. Zunächst rekapituliere ich jedoch, was die Funktion bisher macht und wann es sinnvoll ist diese einzusetzen.

Wozu register_meta() gut ist

Um ein benutzerdefiniertes Feld mit register_meta() zu registrieren übergibt man zunächst den Typ des Metafelds. Es gibt Felder für Beiträge, dann wäre dieser Typ 'post'. Es gibt Benutzer, dann wäre dieser Typ 'user' und so weiter. Danach übergibt man den Schlüssel des neuen Feldes und erst danach wird es interessant. Als dritten Parameter kann man einen Callback übergeben, der die Daten “reinigt”, denn 'sanitize_callback'.

Dieser Callback wird als Filter genutzt, um Meta-Daten zu “reinigen”, bevor diese in der Datenbank abgelegt werden. Wenn Du beispielsweise sicherstellen möchtest, dass es sich nur um Integer handelt, so könntest Du wie folgt vorgehen:

Jedes Mal, wenn nun mit update_post_meta() oder add_post_meta() (beziehungsweise schlussendlich mit update_metadata() und add_metadata()) der Wert aktualisiert wird, würde nun Deine Reinigungsfunktion durchlaufen. Wenn also der Autor eines Beitrags das benutzerdefinierte Feld über die entsprechende Schnittstelle im Beitragseditor ändert oder aber auch ein anderes Plugin Deinen Metawert aktualisiert kannst Du so sicherstellen, dass nicht unerwartet plötzlich ein String hinterlegt wäre.

Der vierte Parameter übergibt einen weiteren Callback, mit dem Du ein Feld als “protected” definieren kannst. Weitere Informationen dazu gibt es in meinem Beitrag Geschützte Metafelder.

Es kommt Bewegung in die Sache

Also, insgesamt ist register_meta() schon jetzt eine recht interessante Funktion, auch wenn die Reinigung der Daten häufig an anderer Stelle vorgenommen wird oder eben direkt der entsprechende Filter mit add_filter( "auth_{$meta_type}_meta_{$meta_key}", callback ) Verwendung findet. So führt register_meta(), liest man mal die Quellcodes verschiedener Plugins, ein Nischendasein. Doch dies könnte sich langsam ändern. Der Grund dazu sind die derzeitigen Diskussionen rund um die REST API, welche (wenn es denn tatsächlich dazu kommen wird) derzeit mit WordPress 4.7 in den Core kommen soll. Wenn Du nicht weißt, um was es sich bei der REST API handelt, empfehle ich Dir das Merge Proposal, welches im September 2015 veröffentlicht wurde. Ich will dazu immer nochmal einen Beitrag schreiben, bin aber noch nicht dazu gekommen.

Die REST API wird also Beiträge und vieles mehr über eine JSON-Schnittstelle zur Verfügung stellen. Auf dieser Grundlage ergibt sich an ganz neuer Horizont an Einsatzmöglichkeiten für WordPress, neuen Plugins, aber auch anderen Services rund um WordPress. Diskutiert werden mobile Apps auf der Grundlage von WordPress zu erstellen, WordPress quasi nur noch als Datenlieferanten zu nutzen, abgekoppelte Administrationsoberflächen zu verwenden und vieles mehr. Keine Sorge, WordPress bleibt dennoch WordPress, die Idee ist eher Horizonte zu erweitern und nicht, diese einzuschränken.

Sagen wir, man ruft nun einen Beitrag über diese Schnittstelle ab, man erhält also den Titel, den Inhalt und so weiter. Mit Metadaten kommt man hier allerdings in vielerlei Hinsicht an seine Grenzen, einmal technisch und zum anderen gilt es sicherheitsrelevante Aspekte zu beachten, sowie nicht-öffentliche Daten. Zu den technischen Problemen: Metadaten sind nicht einfach nur Strings oder Integer, man kann auch serialisierte Daten hinterlegen mitunter PHP-Objekte. Das führt zu Problemen, wenn es darum geht, diese über JSON auszugeben oder über die REST API zu aktualisieren und so waren serialisierte Daten immer ein Blocker in der Entwicklung. Schreibzugriff auf serialisierte Daten kann schließlich dazu führen, dass arbiträrer Code in die WordPress Installation geladen werden könnte, was nicht gerade ein zu vernachlässigendes Sicherheitsrisiko darstellt. Schließlich gibt es noch Probleme mit Daten, welche schlicht nicht öffentlich zugänglich sein sollen. Die Kontrolle, welche Metadaten öffentlich sichtbar sind, oblag bisher immer den Plugins oder Themes, welche diese Daten erhoben und verwendeten. Dies ermöglicht auch Daten zu hinterlegen, welche beispielsweise nur bestimmte Benutzergruppen einsehen können sollen. Sagen wir, ein Onlineshop hinterlegt die Anzahl der Verkäufe eines Produkts als Meta-Information: Möchte man diese Information tatsächlich über die REST API öffentlich zugänglich sehen?

Auf der anderen Seite wäre es natürlich fantastisch, Metadaten über die API zugänglich zu machen, da dies die Einsatzmöglichkeiten der API drastisch erhöht. Man stelle sich vor, man könnte nicht nur Beiträge einer bestimmten Kategorie ausgeben lassen, sondern auch Beiträge, welche eine bestimmte Metainformation hinterlegt haben. Der bisher bestehende Filter greift letztlich auf den WP_Query zurück und viele der dort vorhandenen Filtermöglichkeiten können genutzt werden. Der WP_Meta_Query ist aber aus den oben genannten Gründen explizit zunächst ausgenommen und nur Daten, welche schon öffentlich sind können zum Filtern herangezogen werden. Liest man sich die Issues auf Github mal durch sieht man, wie häufig diese Ausnahme für Irritationen sorgt und es gibt ein großes Bedürfnis Metadaten irgendwie zur Filterung heranziehen zu können.

Nach diesem langen Umweg: Die Frage ist also, wie könnte man feststellen, dass eine Metainformation öffentlich zugänglich sein soll und die Antwort ist register_meta() und die dazu notwendigen Erweiterungen sollen mit WordPress 4.6 in den Core kommen und werden derzeit im Ticket “Provide additional data for registered meta through register_meta()” bearbeitet.

Wie ist der Stand der Dinge?

Derzeit läuft hier die Entwicklung natürlich noch auf Hochtouren, aber es zeichnet sich ab, dass register_meta() nun eine Wrapper-Funktion wird für die neue Klasse WP_Meta_Manager. Statt vier Parametern übergibt man nunmehr drei. Die ersten beiden Parameter, Metatyp (beziehungsweise “Objekttyp”) und Metakey bleiben erhalten und als dritten Parameter kann man nun einen Argumentearray übergeben. register_meta() übernimmt nun die Aufgabe, die Abwärtskompatibilität festzuklopfen und führt danach $wp_meta_manager->register() aus. An diese wird nun ein Argumentenarray übergeben. Die Default-Werte geben Aufschluss, was hier passiert:

  • 'object_type': Das ist der bisher als erster Parameter übergebene Typ
  • 'object_subtype': Bisher war es nur möglich, beispielsweise für Beiträge ('post') Metafelder zu registrieren. Dies bezog sich dann aber auch auf alle anderen Posttypen wie beispielsweise 'page'. Mit dem Subtypen wird man hier nochmal spezifischer eine Metainformation für einen bestimmten Posttype registrieren können. Der Default-Wert ist hierbei 'all'
  • 'key': Der Metaschlüssel
  • 'public': Ein Boolean, ob diese Information öffentlich zugänglich sein soll
  • 'show_in_rest': Ein Boolean, ob diese Information über die REST API zugänglich sein soll. Es bleibt abzuwarten, wie das Zusammenspiel zwischen public und show_in_rest zum Schluss sein wird. Es ist auch möglich, dass eines der beiden Argumente am Ende einfach wieder aus dem Code fliegt.
  • 'sanitize_callback': Der “neue” Reinigungscallback
  • 'old_sanitize_callback': Der “alte” Reinigungscallback welcher für die Abwärtskompatibilität erhalten bleibt
  • 'auth_callback': Der “neue” Auth-Callback
  • 'old_auth_callback': Der “alte” Auth-Callback welcher für die Abwärtskompatibilität erhalten bleibt

Was ist der Unterschied zwischen den alten und den neuen Callbacks? Ein Blick in die setup_hooks() hilft weiter: Derzeit ist vorgesehen, dass die Konstruktion der neuen Filter um den Objektsubtypen erweitert werden. Bisher wurde die Reinigung über den Filter "sanitize_{$object_type}_meta_{$meta_key}" vorgenommen. Ein mit 'old_sanitize_callback' übergebener Callback wird auch weiter über diesen Filter eingehakt. Der neue Reinigungsfilter soll nun spezifischer auch den Objektsubtypen einbeziehen, so dass man bis runter auf die CPT-Ebene den Filter bestimmen kann: "sanitize_{$object_type}_{$object_subtype}_meta_{$meta_key}". Die neue Funktion sanitize_meta() würde nun beide Filter durchlaufen.

Ist das jetzt nur interessant für die REST API

Derzeit finden diese Überarbeitungen tatsächlich ausschließlich in Bezug auf die REST API statt. Das heißt aber nicht, dass es so bleiben muss oder das nicht auch andere Plugins sich diese erweiterten Informationen zu Nutze machen würden. Die Absicht ist derzeit, dass 'public' den Status übermittelt, ob ein Wert öffentlich zur Verfügung stehen soll und auch ob er beispielsweise als öffentlicher Filter taugt. Es ist nur so eine Überlegung, aber öffentliche Filter, dass sind ja eigentlich die allseits bekannten public_query_vars, wie z.B. 'year'. Diese können genutzt werden um Beiträge via URL zu filtern. Ein Beispiel: https://websupporter.net/blog/de?year=2015 gibt alle Beiträge aus dem Jahr 2015 aus. Warum sollte ein 'public'-Parameter nur für die REST-API interessant sein. Denkbar ist natürlich auch, dass sich daraus ähnliche Filter-URLs konstruieren liesen. Für andere Plugins ergibt sich hier sicherlich ein spannendes Feld.

Auch das man nun eben sehr viel spezifischer seine Reinigungs- und Auth-Callbacks einstellen kann weist natürlich über die REST API hinaus.

Metadatenschema

Derzeit in der Diskussion ist noch der ganze Bereich um das Schema. Prinzipiell soll es wohl auch möglich sein, dass Datenschema mit zu übergeben. Dieses Schema würde die im Feld hinterlegten Informationen nochmal weiter spezifizieren. So würde der Datentyp hinterlegt, sowie eine Beschreibung. Tatsächlich gehen die Ambitionen weit darüber hinaus, wenn man sich den derzeitigen Blogbeitrag auf w.org/core ansieht. Hier ist die Diskussion noch in vollem Gange aber es zeichnet sich ab, dass das Metadaten-Konzept um ein Metadaten-Schema-Konzept erweitert wird!

Ein Feld deregistrieren

Mit unregister_meta_key() soll darüber hinaus die Möglichkeit Einzug halten, ein Metafeld auch wieder abzumelden, ähnlich wie man auch Custom Post Types mit unregister_post_type() wieder abmelden kann. Übergeben wird dabei der Typ, der Schlüssel sowie der Subtyp. Der Subtyp-Default ist dabei 'all'

Fazit

In die lange vernachlässigste Funktion register_meta() ist also Bewegung gekommen und spätestens wenn Du Dich wunderst, warum Deine Metadaten nicht über wp-json/wp/v2/posts/1/meta abrufbar sind (sein werden 😀 ), solltest Du einen näheren Blick auf die Entwicklung werfen. Ab sofort kann man hierüber festlegen, welche Metadaten tatsächlich öffentlich zugänglich sein sollen, was eine einschneidende Neuerung des Metadaten-Konzeptes darstellt und der Fantasie mal wieder einen neuen Raum zum austoben bietet.