WordPress-Wochenrückblick KW40: Responsive Images, oEmbed-API und mehr
Veröffentlicht am
In dieser Woche wurden nach dem letztwöchigen Vorschlag zur Core-Integration der REST API zwei weitere Vorschläge veröffentlicht. Für das Responsive-Image-Feature und die oEmbed-API. Daneben gab es den zweiten Entwurf der Shortcode-Roadmap.
Accessibility
Im dieswöchigen a11y-Meeting ging es hauptsächlich weiter um die Überarbeitung der Überschriften-Hierarchien im Backend.
Core
Zweiter Entwurf der Shortcode-Roadmap
Vor einiger Zeit wurde in der ersten Roadmap eine neue Syntax für Shortcodes vorgeschlagen. Da dieser Vorschlag viel Kritik hervorgerufen hat, wurde der Entwurf grundlegend überarbeitet.
WordPress 4.4
Der neue Vorschlag sieht vor, dass die alte Syntax grundsätzlich beibehalten aber ein neues Trennzeichen eingeführt wird, damit HTML-Code nicht direkt in den Shortcode-Tags eingefügt werden kann/muss.
[photo link_to="twentysixteen/"] Here is <b>my</b> caption. [photo:media=] <imgsrc="00.twentysixteen-260x300.png"width="260"height="300" /> [/photo]
Code-Sprache:HTML, XML(xml)
In dem Beispiel funktioniert der name-Teil des Trennzeichens wie ein Attribut-Name. Zudem ist es nicht mehr erlaubt, Spitzklammern in den Namen von Shortcodes zu verwenden (was aber bereits länger bekannt und seit über einem Jahr dokumentiert ist).
WordPress 4.5
Ein weiterer Teil der Roadmap ist die Veränderung der Filter-Prioritäten. Bisher ist es so, dass es einige Extra-Funktionen und komplizierte reguläre Ausdrücke in der API gibt. Und zwar nur, weil ein paar Filter vor der Verarbeitung von Shortcodes ablaufen. Das soll geändert werden.
WordPress 4.6
Ab WordPress 4.6 wird kein HTML mehr innerhalb von Shortcode-Tags gespeichert. Wenn ein Shortcode in einem neuen Beitrag oder in einem Beitrag, der bearbeitet wird, eine Spitzklammer enthält, dann wird diese durch ein Leerzeichen ersetzt. Das sieht dann beispielsweise so aus:
Input 1:
[shortcode attr="Hello & it is <b>my</b> title"]
Output 1: [shortcode attr="Hello & it is b my /b title"]
WordPress 4.7
Ab WordPress 4.7 werden Shortcodes, deren Attribute HTML enthalten, ein leeres Ergebnis zurückgeben. Das heißt, dass eventuell auch alte Beiträge angepasst werden müssen. Hier ein Beispiel:
==API 4.6==
Input: [shortcode insert="fun"]
Output: My fun link is here.
Input: [shortcode insert="<a>"]
Output: My <a> link is here.
Output: My <a> link is here.
==API 4.7==
Input: [shortcode insert="fun"]
Output: My fun link is here.
Input: [shortcode insert="<a>"]
Output:
Input: [shortcode][shortcode:insert=]<a>[/shortcode]
Output: My <a> link is here.
Auch Shortcodes innerhalb von HTML-Attributen sind betroffen. Das sieht dann so aus:
==API 4.6==
Input: <atitle='[shortcode insert="fun"]'>
Output: <atitle='My fun link is here.'>
==API 4.7==
Input: <atitle='[shortcode insert="fun"]'>
Output: <atitle='[shortcode insert="fun"]'>
Code-Sprache:HTML, XML(xml)
Sehr viel genauer findet ihr den zweiten Entwurf in dem Beitrag von Robert Chapin auf Make/Core beschrieben:
Hier klicken, um den Inhalt von make.wordpress.org anzuzeigen
Vorschlag zur Core-Integration der oEmbed-API
Nach der REST API ist nun auch die oEmbed-API bereit für die Integration in den Core. Das Plugin wurde so entwickelt, dass es möglichst wenig Probleme beim Einfügen in den Core gibt, ein paar Dinge müssten allerdings im Core angepasst werden. Daneben gibt es noch ein Problem mit Slack (das inzwischen behoben wurde), das die Ausgabe des oEmbed nicht richtig darstellt und ein paar kleine Layout-Probleme.
Genauere Informationen findet ihr in dem Beitrag von Pascal Birchler auf Make/Core:
Hier klicken, um den Inhalt von make.wordpress.org anzuzeigen
Im Meeting des #core-Channels wurden noch einige Fragen geklärt und Wünsche geäußert. So gibt es bisher keinen Fallback mit reinem Text, wie ihn etwa Twitter bereitstellt. Das lässt sich aber wohl relativ einfach implementieren und wird noch angegangen. Auch eine einfache Option (keine visuelle sondern über einen Filter), dieses Feature komplett zu deaktivieren und zu verhindern, dass andere Seiten die eigene auf diesem Weg einbetten, wird wohl noch implementiert.
Core-Integration von Responsive Images
Auch das Team hinter dem Plugin für Responsive Images in WordPress hat einen Vorschlag zur Core-Integration verfasst. Hierbei geht es um eine teilweise Integration des Plugins, um das srcset- und sizes-Attribut für WordPress nachzurüsten (#33641).
Basierend auf Community-Feedback wird kein Polyfill für ältere Browser integriert. Es wird aber empfohlen, dass Themes Picturefill benutzen. Das Plugin bringt auch bessere Kompressions-Einstellungen für den Imagick-Editor mit. Diese Verbesserung ist aber zum jetzigen Zeitpunkt nicht Teil des Vorschlags zur Integration. Genauere Infos gibt es im Beitrag von Joe McGill auf Make/Core:
Hier klicken, um den Inhalt von make.wordpress.org anzuzeigen
Beim #core-Meeting wurde der Punkt angesprochen, dass das Plugin mit den aktuellen Standard-Bildgrößen von WordPress keinen großen Nutzen für Nutzer haben könnte/wird. Die Diskussion kam deshalb auch zu dem Punkt, ob eine weitere Bildgröße eingeführt werden sollte.
Core-Integration von REST API, Responsive Images und oEmbed in WordPress 4.4
Alle drei Vorschläge für die Integration in den Core von REST API, Responsive Images und oEmbed-API haben ein „Okay“ bekommen. Für die oEmbed-API gibt es auch bereits die erste Version eines Core-Patches.
Richtlinien zur Erstellung von Beiträgen auf Make/Core
Das Thema kam bei der Bewertung des 4.3-Release auf die Agenda. In seinem Beitrag auf Make/Core schlägt Aaron Jorbin folgende Richtlinien vor:
Alle API-Änderungen sollten schnellstmöglich einen Beitrag auf Make/Core bekommen. Am besten innerhalb der ersten Beta-Phase-Woche.
Jeder Beitrag sollte vorher von einem Committer gegengelesen werden. Beiträge zur Integration in den Core sollten immer vom Release-Lead oder Vertretern gelesen werden. Gleiches sollte für Release-Dev-Notes gelten.
Die persönliche Meinung sollte nicht Teil eines Beitrags sein. Erste Person Singular sollte vermieden werden, ebenso „Wir“, wenn nicht genau klar ist, welche Gruppe damit gemeint ist. Darüber hinaus sollte bei der Formulierung im Hinterkopf behalten werden, dass viele Leser Englisch nicht als erste Sprache sprechen. Die Formulierung sollte wie WordPress sein: freundlich.
Man sollte immer den Zeit-Shortcode nutzen, wenn man Meetings ankündigt, sodass alle Besucher ihre lokale Zeit sehen. Zudem sollte der Slack-Channel genannt werden, in dem das Meeting stattfinden wird.
Die Beiträge sollten sinnvoll mit Tags versehen werden.
Diverses
Vielleicht wird wegen der Responsive-Images-Funktion eine weitere Bildgröße zwischen Medium und Large hinzugefügt
Die oEmbed-API liegt seit dieser Woche in Version 0.9.0 vor. Damit gibt es nun einen Conditional-Tag is_embed, um eingebettete Beiträge zu identifizieren. Außerdem können nun Video- und Audio-Dateien eingebettet werden. Zudem kann jetzt der gesamte Code für die Einbettung aus dem Teilen-Dialog kopiert werden, nicht mehr nur die URL. Weitere Informationen findet ihr in dem Post von Pascal Birchler auf Make/Core:
Hier klicken, um den Inhalt von make.wordpress.org anzuzeigen