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/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.