Schlicht – Das neue WordPress Theme für meinen Blog

Das Schlicht Theme

Beginnen wir erst einmal damit, das Alte zu Grabe zu tragen: Ich glaube, ich hatte jetzt zwei oder drei Jahre hier im Blog immer das gleiche Theme laufen: Gumbo. Ich kann auch überhaupt nichts Schlechtes über das von Themato Soup erstellte Theme sagen; Es ist immer noch ein schickes Blogdesign. Eines der wenigen im Repository, welches hält was es verspricht und tatsächlich etwas verspricht. Zwar heißt es dort mittlerweile, dass es seit über zwei Jahren nicht mehr aktualisiert worden ist, da es aber wirklich ein solide gearbeitetes Theme ist, läuft das nach wie vor und ich glaube, es wird auch noch einige Zeit laufen.

Aber nach so langer Zeit wurde ich einfach etwas müde, auf meinen Blog zu schauen. Nur konnte ich mich nie aufraffen, mal ein anderes Design auszuwählen oder gar selbst aufzusetzen. Meine Fähigkeiten in dies Richtung sind auch eher beschränkt. Ich hatte schon ein bisschen mit Hannover geliebäugelt. Florian Brinkmann hat da einfach ein Händchen für schöne Blogdesigns. Aber so richtig durchringen konnte ich mich nicht.

Dann flog vor einiger Zeit ein Tweet über meine Timeline und ich wusste, wie mein Blog in Zukunft aussehen würde:

https://twitter.com/FloBrinkmann/status/804350472391888896

Schlicht hat eigentlich schon alles im Namen. Es kommt in einem schlichten und zurückhaltenden Design und ist überwiegend in Grautönen gehalten. Ich hätte ja nicht gedacht, dass ich einmal mit einer Serifenschrift im Block enden würde, aber das von Florian gewählte Sorts Mill Goudy hat es mir tatsächlich angetan und mit einer guten Schriftart fängt eigentlich jedes gute Blogdesign an.

Über den Customizer kann man zwischen zwei Grundlayouts wählen. Das erste Layout könnt Ihr in meinem Blog sehen, dass Zweite finde ich aber auch sehr schick. Die Überschrift findet sich dann links mit den ganzen Metadaten wie Autoren, Datum und so weiter und rechts dann der Beitrag. Ich hätte das zweite Layout gewählt, wenn ich nicht meine Sidebar dadurch verlieren würde, mit der ich Euch (jetzt in rot) auf mein Buch aufmerksam machen möchte. Beides zusammen ging leider nicht und so habe ich mich für die erste Variante entschieden.

Darüber hinaus kann man auch Initiale einschalten, wie man es aus Zeitungen oder Büchern kennt. Hier weiß ich noch nicht so recht und habe diese erst einmal nicht aktiviert. Neben der Sidebar gibt es noch einen Widgetbereich im Footer und man kann auch zwei Menüs einrichten. Für diesen Blog habe ich einfach schnell im Footer ein Menü für Impressum und dieses Zeug eingerichtet.

Schlicht ist Florian Brinkmanns erstes kommerzielles Theme und man kann es für 15 Euro direkt auf seiner Seite erwerben. Wenn man es herunterlädt kommt es gleich mit einem Child Theme zusammen, was einem die Mühe erspart, da selbst erst wieder eines zusammenzustöpseln. Das ist auf jeden Fall top. Darüber hinaus gibt es einen Updater, so dass ihr das Theme selbst ganz bequem über das Backend aktualisieren könnt, wie jedes Design, welches ihr über das WordPress Repository beziehen würdet.

Ja, ich habe ein neues Theme 🎉. Gefällt es Euch auch so sehr wie mir?

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

BuddyPress 2.7 ist auf dem Weg

Gestern wurde die Beta-Version von BuddyPress 2.7 vorgestellt. Die finale Version soll schließlich Mitte Oktober erscheinen. Eines meiner liebsten Erweiterungen ist dabei die überarbeiteten Profilfelder, die jetzt über einen Date-Selector verfügen!

Der neue Date-Selector
Der neue Date-Selector in BuddyPress 2.7

Darüber hinaus wurde erneut am Templatesystem gearbeitet, sowie etliche Performancegewinne erzielt. Gelungen finde ich auch den “Unsubscribe”-Link für Email-Abos. Ab sofort muss man sich dazu nicht mehr einloggen, sondern der Link übernimmt die Abmeldung automatisch und das ist sicherlich viel Wert.

Um 2.7 zu benutzen muss man allerdings mindestens WordPress 4.2 verwenden. Eine Liste aller Änderungen, welche in die neue Version bisher eingeflossen sind, findet sich hier. Die entsprechende Ankündigung hier.

Es ist immer gut, wenn Beta-Versionen von möglichst vielen unterschiedlichen Usern getestet werden, dazu kann man sie hier herunterladen. Denkt aber daran, dass Beta-Versionen nicht für den Produktiveinsatz gedacht sind und mit hoher Wahrscheinlichkeit noch Bugs enthalten. Je mehr Leute allerdings diese Betas durchtesten, desto stabiler wird die endgültige Version schließlich sein. Wenn ihr beim Testen auf ein Problem stoßt, so solltet ihr das Supportforum aufsuchen und dort davon berichten, damit das Problem behoben werden kann, bevor die stabile Version veröffentlicht wird.

Wenn Du BuddyPress bisher noch nicht kennst, hier habe ich einen kleinen Beitrag verfasst was BuddyPress alles kann.