WordPress-Wochenrückblick KW4: HTTPS, a11y-Coding-Standards und mehr

In der letzten Woche gab es im #core-http-Channel ein Meeting, das sich mit verschiedenen Punkten auseinandergesetzt hat, wie https besser von WordPress unterstützt werden kann – beispielsweise über Konstanten, die das Erzwingen von https für eine Website ermöglichen.

Accessibility

Coding-Standards mit Fokus auf a11y

Im Core-Handbook wurde ein Entwurf für die Accessibility-Coding-Standards veröffentlicht. Aaron Jorbin erklärt in seinem Post auf Make/Core, dass dieser Entwurfstatus mindestens zwei Wochen erhalten bleiben wird, während denen jeder die Möglichkeit hat, Kommentare und Verbesserungsvorschläge dazu abzugeben. Wenn es große Änderungen gibt, wird das in weiteren Beiträgen kommuniziert werden, sodass auch diese Änderungen wieder diskutiert werden können.

Diverses

  • Es wurde damit angefangen, Tickets für mangelhafte Farbkontraste im Backend zu erstellen
  • Die Funktion für das Inline-Bearbeiten und Hinzufügen von Links muss getestet werden, speziell auf den Aspekt der Tastaturbedienbarkeit hin (#33301)
  • Im Make/Accessibility-Bereich soll eine About-Seite oder ähnliches eingerichtet werden
  • Ticket für die Optimierung des Tag-Cloud-Widgets (#35566)

Core

Responsive-Design-Vorschau im Customizer

Für den Customizer wird an einer Funktion gearbeitet, die es dem Nutzer ermöglicht, die Vorschau neben der großen Ansicht auf eine Tablet- und Smartphone-Größe zu bringen (#31195). Den aktuellen Stand hat Nick Halsey in einem Beitrag auf Make/Core zusammengefasst. So wird es möglich sein, die Funktion via Filter entweder zu deaktivieren oder auch zu erweitern. Ein weiterer Gedanke ist, eine Vorschau für einen größeren Viewport zu ermöglichen, als der Nutzer selbst nutzt – in dem Fall würde ein horizontaler Scollbalken eingesetzt werden (#34051).

WP REST API 2.0 Beta 11

Am 26. Januar wurde die elfte Beta der WP REST API 2.0 veröffentlicht. Mit der neuen Version wurde die Post-Term-Beziehung in die Post-Ressource verlagert. Die Terme eines Posts können nun so geholt werden: GET /wp/v2/tags?post=<id>. Darüber hinaus wurde das featured_image-Attribut in featured_media umbenannt. Weitere Neuerungen gibt es im Beitrag von Daniel Bachhuber.

HTTPS-Meeting

Am 27. Januar hat ein Meeting zur HTTPS-Unterstützung von WordPress stattgefunden. Themen waren die drei folgenden:

  1. Einbinden einer Option, um https auf einer Website zu erzwingen
  2. Eine neue Installation mit https ausführen, falls verfügbar – auch, wenn die Installation über http aufgerufen wird
  3. Nutzer beim Wechsel von http zu https mit einer bestehenden Site unterstützen

Ergebnis des Meetings war, dass zuerst das granulare Erzwingen von https durch einige Konstanten ermöglicht werden soll – dafür wird ein Feature-Plugin auf GitHub entwickelt. Anschließend kann sich dem Punkt der Installation über https angenommen werden.

Shiny Updates v2

Auf Make/Core wurde der aktuelle Stand des Shiny-Updates-Plugins zusammengefasst. Das Plugin entfernt die Seite, die im Backend beispielsweise bei der Installation eines Plugins geladen wird, und schiebt die Installation in den Hintergrund. Diese Funktion ist im Plugin schon für viele Fälle integriert, beispielsweise für die Deinstallation von Plugins sowie Installation, Update und Deinstallation von Themes et cetera.

Darüber hinaus wird über die Überarbeitung der Core-Update-Seite nachgedacht, um mehr Klarheit zu schaffen und eine einfachere „Alles aktualisieren“-Funktion zu ermöglichen.

Application-Passwörter als eigenes Plugin

Application-Passwörter im Backend erzeugen. (Screenshot: WordPress.org)
Application-Passwörter im Backend erzeugen. (Screenshot: WordPress.org)

Als Teil des Zwei-Faktor-Authentifizierung-Plugins gestartet, wurde der Teil für Application-Passwörter nun in ein eigenes Plugin abgespalten. Grund dafür ist, dass dieser Teil im Gegensatz zu dem gesamten Plugin nahezu fertiggestellt ist und gut zu der REST API passt. Das Plugin lässt den Nutzer 16-stellige Passwörter erstellen, die dem Nutzer nur einmalig angezeigt werden, nachdem sie generiert wurden.

Diese können dann für Dienste genutzt werden, die mit der WordPress-Installation kommunizieren, beispielsweise der WordPress-App für das Smartphone oder IFTTT, sodass jeder Dienst ein eigenes Passwort hat. Im Backend werden Einträge zu den verschiedenen Passwörtern dargestellt, die unter anderem zeigen, welche IP das Passwort als letztes genutzt hat. Darüber hinaus kann das Passwort hier auch wiederrufen werden, beispielsweise wenn ein Gerät verloren gegangen ist. Nähere Infos gibt es im Beitrag von George Stephanis auf Make/Core.

Diverses

Polyglots

Diverses

  • Die Erwartungen einiger Nutzer an das Polyglots-Team sind zu hoch – es muss klarer kommuniziert werden, was vom Team erwartet werden kann, und was nicht
  • Polyglots-Meeting-Notizen

Theme Review Team

Werbung in Themes

Viele Themes im Theme-Verzeichnis bieten neben der kostenlosen auch eine kostenpflichtige Version an, und deren Autoren möchten (verständlicherweise) in der freien Version auf die Möglichkeit des Upgrades verweisen. Das kann entweder recht dezent passieren oder beispielsweise durch eine immer sichtbare Notiz auf jeder Seite des Backends.

Justin Tadlock hat auf Make/Themes eine Diskussion darüber angestoßen, um folgende Frage zu klären: „What solutions do you have in mind for balancing between providing free themes and upselling/marketing?“. Wenn ihr euch daran beteiligen wollt, schreibt einfach einen Kommentar unter den Artikel von Justin.

Docs

HelpHub-Development-Kickoff

Im dieswöchigen HelpHub-Meeting wurde nicht viel über die inhaltliche Seite diskutiert, da einige Leute aus dem Bereich nicht teilnehmen konnten. Dafür wurde das Team für die Entwicklung sowie der Workflow festgezurrt – näheres dazu im GitHub-Repo des HelpHub-Projekts.

Für die Theme-Basis wird _s genutzt, mit dem Standard-Header und -Footer von WordPress.org.

Plugins

Schlechten Code finden

Das Plugin-Team müsste theoretisch jedes Plugin manuell prüfen, um schlechten Code in Form von Hacks und ähnlichem zu vermeiden, kann das bei 600 bis 1.000 Checkins pro Tag aber einfach nicht leisten. Deshalb hat Mika Epstein auf Make/Plugins gefragt, wie man Hacks und andere unschöne Code-Stellen besser automatisiert finden kann.

Schreibe einen Kommentar

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