WordPress-Wochenrückblick KW39: Core-Integration der WP REST API, mögliche Customizer-Roadmap und mehr

In dieser Woche wurden die Testergebnisse des a11y-Teams für das neue Standard-Theme Twenty Sixteen vorgestellt. Zudem sollten Entwickler von Term-Meta-Plugins oder anderen Lösungen von Term-Metainformationen jetzt ihren Code überprüfen, damit es keine Probleme mit der geplanten Core-Umsetzung gibt.

Accessibility

Testergebnisse zu Twenty Sixteen

Da der Prozess der Fertigstellung von Twenty Sixteen schon ziemlich weit vorangeschritten ist, wurde dem Accessibility-Test-Team das neue Standard-Theme übergeben.

Die Tester konnten keine gravierenden Fehler feststellen. Einige der gefundenen Probleme habe ich euch hier aufgelistet:

  • Fehlender Kontext für sehende Nutzer bei den Autoren-, Kategorie- und Tag-Links. Könnte damit auch ein Usability-Problem sein.
  • Die Nutzung der Navigation ist via Tastatur manchmal etwas umständlich, da es keine Möglichkeit gibt, gleich zum nächsten Oberpunkt zu springen. Genau dasselbe Problem gibt es auch für Nutzer von Screenreadern.
  • Der Farbkontrast bei Rand und Hintergrund von Eingabefeldern könnte größer sein.
  • Ein paar Elemente mit fehlender Hervorhebung beim Fokus.

Die umfangreichen Testergebnisse könnt ihr im Beitrag von Rian Rietveld auf Make/Accessibility nachlesen.

Diverses

  • Verbesserung der Barrierefreiheit des Suchformulars (#33952)

Core

Vorbereitung auf Term-Meta

Wie bereits im Wochenrückblick zur KW 36 geschrieben, soll es möglich werden, Meta-Informationen zu Termen wie beispielsweise Kategorien hinzuzufügen (#10142). Dabei kann es zu Problemen mit Lösungen von Plugins oder speziellen Lösungen für Kunden kommen. Hauptsächlich verantwortlich sind die folgenden Gründe:

  1. Überschneidung von Funktionsnamen. Der Vorschlag zur Implementierung in den Core führt einige neue Funktionen ein, wie etwa add_term_meta() und get_term_meta(). Wenn Plugins dieselben Funktionsnamen verwenden, müssen diese angepasst werden.
  2. Löschen der Term-Meta-Tabelle. Einige Plugins speichern ihre Meta-Informationen in einer termmeta-Tabelle und löschen diese, wenn das Plugin deaktiviert wird. Wenn nun termmeta aber eine Core-Tabelle wird, wäre diese Praxis nicht gerade wünschenswert. Plugins sollten also niemals diese Tabelle löschen.
  3. Nicht passende Funktionssignatur. Wenn ein Plugin eine Funktion wie get_termmeta() ohne Präfix nutzt, dann sollte doppelt geprüft werden, dass die Reihenfolge und die Standard-Werte der Parameter mit der Core-Implementierung übereinstimmen.
  4. Unpassendes Tabellen-Schema. Wie bereits geschrieben erstellen einige Plugins eine termmeta-Tabelle. Die meisten davon sind laut Boone Gorges wohl nah genug an der voraussichtlichen Core-Implementierung dran, dass sie weiter genutzt werden können. Wenn das Tabellen-Schema aber beispielsweise durch nicht passende Spaltennamen von der Implementierung des Core abweicht, wird das Probleme erzeugen.

Genauere Informationen könnt ihr in dem Beitrag von Boone auf Make/Core einsehen. Dort gibt es auch eine Liste der Plugins von wordpress.org, die davon betroffen sind. Da Term-Meta vermutlich in WordPress 4.4 oder eventuell erst in 4.5 eingeführt wird, sollte jetzt zeitnah gehandelt werden.

Mögliche Customizer-Roadmap

Vor einigen Monaten haben sich die führenden Entwickler von WordPress mir den Verantwortlichen für den Customizer zusammengesetzt und darüber gesprochen, wie die Zukunft der Live-Vorschau in WordPress aussehen soll. Daraus haben sich letztlich folgende Ziele für die nächsten zwei Jahre ergeben:

  • Die Performance deutlich verbessern.
  • Verbesserung aktueller Live-Preview-Funktionen wie der Theme-Auswahl, Menüs und Widgets.
  • Mit neuen Benutzeroberflächen experimentieren mit den Fragen im Hinterkopf: Wie würden wir Live-Vorschau heute umsetzen? Wie würde es aussehen?
  • Entfernen des mehrdeutigen Modus. Aktuell ist der Customizer in einer Sidebar ohne die Admin-Toolbar. Idealerweise gäbe es nur das Backend und Frontend, und nichts dazwischen. Ein möglicher Weg wäre, dass der Customizer im Frontend aktiviert wird und unmittelbar die Customizer-Funktionen geladen werden.
  • Mit einer geführten „New user experience (NUX)“ experimentieren.

Neben diesen groben Zielen wurden auch einige konkrete Funktionen formuliert, die im Rahmen dieser vorgeschlagenen Roadmap erreicht werden sollten. Auch ein Plan, was in welchen Release kommen könnte, hat Weston Router in seinem umfangreichen Beitrag auf Make/Core festgehalten.

Änderungen bei der Ausgabe von comment_form()

Die Ausgabe der comment_form()-Funktion wird ab WordPress 4.4 verändert. Für nicht angemeldete Nutzer wird das Feld für den Kommentar ganz oben stehen – nicht wie bisher unter den Feldern für Name, E-Mail und Website. Damit soll die Navigation mit der Tastatur verbessert und das Kommentieren für den Endnutzer vereinfacht werden.

Dafür müssen einige Filter und Aktionen jetzt in einer anderen Reihenfolge ausgeführt werden. Wenn ihr Hooks innerhalb von comment_form() nutzt, speziell comment_form_field_comment() und comment_form_after_fields(), solltet ihr euren Code unbedingt mit der letzten Nightly-Version von WordPress testen. Wenn ihr Probleme findet, könnt ihr sie im Ticket #29974 melden. Ein paar weitere Infos gibt es im Beitrag von Aaron Jorbin auf Make/Core.

Vorher-/Nachher-Screenshots bei visuellen Änderungen

Ryan Boren versucht, für alle visuellen Änderungen Vorher-/Nachher-Screenshots mit wenigstens zwei verschiedenen Geräten anzufertigen, von denen eins ein Smartphone sein sollte. Damit sollen unter anderem Reviews vom User Interface erleichtert und ein visuelles Archiv geschaffen werden. Die Screenshots sammelt er dafür direkt in den Tickets.

Alle Tickets, die er gesichtet hat und die noch Screenshots benötigen, versieht er mit dem needs-screenshots-Tag. Wenn mindestens bereits einer vorhanden ist, bekommt das Ticket zusätzlich den has-screenshots-Tag. Sind genügend Screenshots vorhanden, wird der needs-screenshots-Tag entfernt. Ihr könnt ihm dabei helfen und Vorher-/Nachher-Screenshots hochladen. Nähere Infos dazu gibt es im Beitrag von Ryan auf Make/Core.

Diverses

Docs

Erstes HelpHub-Meeting

Im ersten Meeting zum Thema HelpHub wurden einige wichtige Punkte geklärt. Zuerst ging es noch mal darum, was HelpHub überhaupt ist. HelpHub soll die Support-Seiten aus dem Codex ersetzen und so etwas wie eine Wissens-Datenbank werden („Knowledge Base“ soll es aber nicht genannt werden). Des Weiteren haben sich bereits Freiwillige für das Planen der Inhalte, Designer, Entwickler und Autoren für die Inhalte gemeldet.

Die nächsten Schritte sind nun zuerst Wireframing und Planung der Inhalte. Das nächste Meeting wird am 29. September um 15 Uhr stattfinden und den Fokus auf UX und Benutzerfluss legen. Genauere Informationen zu dem ersten Meeting findet ihr im Beitrag von Hugh Lashbrooke auf Make/Docs.

Meta

Die ersten Plugins wurden in translate.wordpress.org importiert. Im Theme Directory gibt es jetzt bei jedem Theme den Link zu der entsprechenden Seiten auf translate.wordpress.org, um eine Übersetzung anzufertigen. Nähere Informationen zum letzten und nächsten Meta-Meeting findet ihr auf Make/Meta.

Feature-Plugins

WP REST API: Vorschlag zur Integration in den Core

Ryan McCue hat auf Make/Core einen Vorschlag für die Integration der WP REST API in den Core veröffentlicht. Darin geht es neben den Hintergründen des Projekts natürlich auch darum, wie diese Integration ablaufen soll. Hier planen die Macher des Feature-Plugins eine Lösung aus zwei Schritten:

  1. Integration der Infrastruktur in den Core mit WordPress 4.4. Die Infrastruktur ist zuständig für Routing-Anfragen und die „Meta“-Schicht der API (Serialisierung/Deserialisierung von JSON …)
  2. Integration der Endpunkte in den Core mit WordPress 4.5. Diese sind verantwortlich für das Mappen der Daten vom externen JSON-Format auf die internen Daten-Strukturen.

Dieser „langsame“ Plan zur Integration ist geplant, damit die API über einen längeren Zeitraum von Core-Committern geprüft werden kann. Genauere Informationen gibt es in dem Beitrag von Ryan.

Prüfung durch alle aktiven Committer

Da die REST API ein sehr großer Schritt in WordPress ist, sollen alle Core-Committer vor der Integration in den Core die API in dem Bereich prüfen, auf dem ihr Fokus in der Arbeit für den Core liegt. Gary Pendergast hat in seinem Beitrag auf Make/Core folgende Bereiche aufgelistet, die er abgedeckt haben möchte:

  • Dokumentation
  • Sicherheit
  • Performance
  • Einfachheit der Nutzung (lassen sich einfach eigene Endpunkte schreiben, wird qualitativ guter Code geliefert)
  • Vorwärtskompatibilität (gibt es Szenarien, wo die Rückwärtskompatibilität in Zukunft eingestellt werden müsste)

Genauere Informationen findet ihr in dem Beitrag von Gary.

oEmbed API

Das oEmbed-API-Plugin liegt jetzt in Version 0.8.0 vor. Wenn der Slug eines eingebetteten Beitrags geändert wurde, leitet das Plugin jetzt zur richtigen URL weiter. Außerdem gibt es eine Ansicht für 404-Fehler. Zudem konnte der Support der REST API dank eines Reviews durch das Team verbessert werden.

Das Plugin kommt nun besser mit Multisite-Installationen und WordPress-Installationen in einem Unterverzeichnis klar. Emojis werden jetzt auch unterstützt. Näheres erfahrt ihr in dem Beitrag von Pascal Birchler auf Make/Core.

Responsive Images

Das RICG-Responsive-Images-Plugin nutzt nun den the_content()-Filter, um das Markup für Responsive Images einzufügen. Hier ein paar Gründe für diesen veränderten Ansatz:

  • Der Wert des sizes-Attributs ist abhängig vom Layout. Darum sollte es Theme-Entwicklern möglich sein, diesen Wert zu verändern. Das wäre aber nicht möglich, wenn das Markup in dem Beitrags-Inhalt gespeichert würde.
  • Vorwärtskompatibilität für den Fall, dass der Nutzer sein Theme wechselt und die Thumbnails neu erstellen muss oder wenn WordPress die Behandlung von Layouts ändert.
  • Erweitert die Unterstützung für Responsive Images auf bereits vorhandene Beiträge.

Nähere Informationen zu den Vorteilen und der Implementierung sowie zu den Möglichkeiten der Unterstützung für die Entwickler findet ihr in dem Beitrag von Joe McGill auf Make/Core.

Schreibe einen Kommentar

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