WordPress-Wochenrückblick KW 11: Browser-Support des Editors und mehr

Der aktuelle Stand beim Thema Browser-Support des neuen Editors ist, dass ältere Browser nicht explizit unterstützt werden sondern ein Fallback in Form eines Textfeldes bereitgestellt wird. Der aktuelle Editors wird in Form eines Plugins bereitgestellt.

Core

Weitere Diskussion zum Browser-Support

In seinem Beitrag »Continued Discussion on Browser Support« hat Jonathan Desrosiers die neuen Vorschläge für einen Editor-Fallback vorgestellt, die im Dev-Meeting vom 8. März vorgeschlagen wurden. Neben der im letzten Wochenrückblick erwähnten Variante von einem Fallback-Mix, gab es unter anderem noch den Vorschlag, automatisch ein Fallback-Plugin zu installieren, wenn ein zu alter Browser erkannt wird.

Zu dem Thema gab es diese Woche noch ein eigenes Meeting.

Browser-Support-Meeting vom 15. März

Im Chat zum Browser-Support wurde eine gute Stunde darüber diskutiert. Das Ergebnis sind die folgenden Punkte:

  • Ein für alle zugänglicher »Text«-Editor ist der beste Fallback. Der neue Editor wird den Support für ältere Browser einstellen.
  • Die aktuelle Editor-Version wird in ein Plugin gepackt.
  • Im Backend wird ein Hinweis für Nutzer von älteren Browsern angezeigt, um die neue Experience zu erklären und auf das Plugin hinzuweisen.
  • Das Editor-Team wird ermitteln, welche Buttons für diese Text-Version des Editors angezeigt werden sollen.
  • Eine allgemeinere Diskussion über Browser-Support-Regeln wird es auf dem Community-Summit vor dem WordCamp Europe geben.

Dev-Meeting vom 15. März

Im Dev-Chat wurden unter anderem die Ergebnisse aus dem Treffen zum Browser-Support vorgestellt. Außerdem wurde dazu aufgerufen, die Medien-Widgets zu testen (vor allem das Bild-Widget) – die neueste Version der Medien-Widgets gibt es auf GitHub.

Verschiedenes

Design

Editor-Meeting vom 15. März

Im Editor-Chat wurde beschlossen, nun langsam mit der Entwicklung eines Feature-Plugins zu beginnen. In diesem Stadium muss sich das Team auch um die Definition der APIs und Datenstruktur kümmern. Mehr Infos zum Meeting findet ihr im Beitrag »🎯 Core Editor Meeting Notes 2017-03-16« von Ahmad Awais.

Plugins

Erläuterung von Richtlinie 8: Ausführbarer Code und Installationen

Seit Jetpack die Möglichkeit der Installation von WordPress.com-Themes auf WordPress.org-Sites angekündigt hat, wurde einige Male nachgefragt, ob das mit der achten Richtlinie des Plugin-Verzeichnisses vereinbar sei, so Mika Epstein in ihrem Beitrag »Clarification of Guideline 8 – Executable Code and Installs«. Die Regel besagt folgendes (übersetztes Zitat):

»Das Plugin darf keinen ausführbaren Code über Drittanbieter-Systeme senden.«

Im Detail gehe es um folgende Teile (erneut übersetzt):

  • »Updates oder die Installation von Plugins, Themes oder Addons über andere Server als WordPress.org bereitstellen.
  • Premium-Versionen vom selben Plugin installieren.«

Kurz: Nein, Jetpack verstößt nicht gegen diese Richtlinie. Bei dieser Regel geht es eher darum, Plugins zu verbieten, die als einzigen Zweck die Installation oder Updates von anderen Dingen haben.

Bei Jetpack ist es außerdem so: Das User-Interface zur Installation von Themes läuft nicht in eurem Backend. Ihr müsst euch auf WordPress.com anmelden, eure WordPress.org-Site damit verbinden und könnt von dort dann Themes installieren. Solche Services sind erlaubt und als weiteres Beispiel dafür nennt Mika ManageWP.

Um einiges detaillierter geht es im Beitrag von Mika zu.

WP-CLI

Verschiedenes

Das könnte auch interessant sein

Schreib einen Kommentar

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