WordPress-Wochenrückblick KW36: Shortcode-Roadmap, Term-Meta und mehr

In dieser Woche wurde eine neue Version des Feature-Plugins RICG Responsive Images vorgestellt, das nun die Voraussetzungen für einen Patch-Kandidaten erfüllen sollte. Auch die Zusammenlegung der beiden Taxonomie-Tabellen in der Datenbank war ein Thema.

Accessibility

Überschriften-Semantik

Wie in den vergangenen Wochen war auch im Meeting dieser Woche wieder ein Punkt die semantische Umstrukturierung der Überschriften. Es wurden einige Tickets zu dem Thema erstellt, die ihr im Core Trac finden könnt.

Accessibility-Probleme mit select2

Für die JavaScript-Bibliothek select2, die eventuell für bessere Auswahlfelder in den Core kommen soll (#31696), wurden Testseiten erstellt, die den Accessibility-Testern geschickt wurden. Das vorläufige Ergebnis ist, dass select2 bei der Barrierefreiheit nicht gerade auftrumpft. Das ist ein Problem, das gelöst werden muss, bevor es in den Core kommen kann.

Dieses Problem haben die Drupal-Entwickler ebenfalls, die jQuery UI gerne durch etwas besseres ersetzen wollen. Vielleicht wird hier gemeinsam an einer Lösung gearbeitet werden:

„i wonder if we can team up with drupal folks to fix these things“

Helen Hou-Sandí im #accessibility-Slack-Channel

Helen Hou-Sandí im #accessibility-Slack-Channel

Core

Shortcode-Roadmap

Die Shortcode-API wird von vielen Entwicklern genutzt. Aufgrund einer mangelhaften Dokumentation allerdings auch für Dinge, die nicht beabsichtigt waren: Gemischt mit HTML-Elementen, verschachtelt et cetera. Shortcodes leben in demselben Kontext wie HTML-Tags und sollten auch so verwendet werden.

<p title="[my-span]">
Code-Sprache: HTML, XML (xml)

So etwas sollte also nicht erlaubt sein. Aus diesen Gründen sollte es eine Roadmap für die Shortcode-API geben, damit diese Probleme aus der Welt geschafft werden können. Nähere Erläuterungen dazu findet ihr in dem Beitrag von Andrew Ozz auf Make/Core.

Erste Version

Robert Chapin hat auf Make/Core einen Vorschlag für eine erste Version dieser Roadmap formuliert. Der Zeitraum dieses Entwurfs erstreckt sich von Version 4.4 bis 4.7. Der erste Punkt darin ist die Einführung einer neuen Syntax für Shortcodes, die nicht mit der Verwendung der eckigen Klammern in der englischen Sprache kollidieren würde, wie es die momentane Syntax tut. Das sähe so aus:

Self-Closing:  [{{shortcode}}]
Attributes:  [{{shortcode  attr1="value1"  attr2='value2'  "value3"  'value4'  value5}}]
Enclosing:  [{{shortcode}$] HTML [${shortcode}}]
Multiple Enclosures:  [{{shortcode}$] HTML [${encl2}$] HTML [${encl3}$] HTML [${shortcode}}]
Escaped Code:  [!{{shortcode}}]
Stripped Unregistered Code:  [{{randomthing}}]
Stripped Unregistered Enclosure:  [{{randomthing}$]  Content also stripped.  [${randomthing}}]
Stripped Empty Code:  [{{ }}]
Ignored Orphan:  [{{shortcode}$]
Ignored Orphan:  [${shortcode}}]
Ignored Orphan:  [${encl2}$]
Ignored Context:  [{{shortcode 
 }}]
Ignored Context:  <a href="[{{shortcode}}]">
Code-Sprache: PHP (php)

Diese Syntax soll nach dem Vorschlag mit WordPress 4.4 eingeführt werden. Die alte Syntax wird dabei nicht verändert. In Version 4.5 soll die alte Syntax dann als Deprecate gekennzeichnet werden. Es werden Debug-Fehler ausgegeben, um die Entwickler auf die endende Unterstützung der alten Syntax hinzuweisen.

Bei dem Upgrade auf WordPress 4.6 soll die Syntax der Shortcodes in alten Beiträgen aktualisiert werden (Shortcodes von Plugins, die die neue Syntax noch nicht unterstützen, sollen nicht umgewandelt werden) und mit WordPress 4.7 sollen alte Shortcodes nicht mehr funktionieren. Zu diesem ersten Entwurf gab es bereits viel Feedback und Kritik – häufig genannt wurde die mit der neuen Syntax zunehmende Komplexität, einen Shortcode einzufügen.

Am 9. September um 19 Uhr wird es ein Meeting im #feature-shortcode-Slack-Channel geben, um einen zweiten Entwurf anzugehen. Robert hat einen Folge-Artikel zu dem ersten Entwurf geschrieben, wo er beispielsweise erklärt, warum eine neue Syntax vorteilhaft wäre.

Trac aufräumen

Aufräumen ist nicht ganz richtig – der Beitrag bei Make/Core von Scott Taylos ist mit „Let’s Garden Trac!“ überschrieben. Darin wendet er sich an die Ersteller von Tickets, an die Ersteller von Patches und an die Besitzer von Tickets. Wenn ihr zu einer dieser Gruppen gehört, dann schaut doch mal in den Beitrag und folgt den Vorschlägen von Scott, um den Trac etwas übersichtlicher zu machen.

Die Komponentenseiten für 4.4 aktualisieren

Die Entwicklung von WordPress wird in Komponenten organisiert. Es gibt beispielsweise eine Komponente „Datenbank“ und eine „Editor“-Komponente. Die Einzelseiten sollen die Komponenten beschreiben, Meilensteine beziehungsweise die Roadmap darstellen und aufzeigen, was getestet werden muss und wie es getestet werden kann. Damit richtet sich dieser Bereich an die Beta-Tester.

Diese Seiten sind nicht alle auf dem aktuellen Stand und müssen deshalb aktualisiert werden. Ryan Boren hat dazu einen Artikel auf Make/Core geschrieben.

Term-Meta

Von vielen bereits seit längerem herbeigeseht wird dir Möglichkeit, Taxonomie-Terme mit weiteren Metadaten anzureichern – beispielsweise Icons oder Bilder für Kategorien anzulegen et cetera. Im #core-Slack-Channel gab es dazu ein Meeting unter der Leitung von Boone Gorges. Eine der größten Bedenken bei dem Metadaten für Terme ist die Performance.

Die „naive“ Implementierung würde so aussehen:

„- a wp_termmeta table, aliased at $wpdb->termmeta
- CRUD wrappers add_term_meta(), update_term_meta(), etc
[...]
- An upgrade routine (as part of upgrade_440() or whatever) that creates the table
[...]
Oh, and tax_query for get_terms() and probably for wp_get_object_terms()
along with the requisite update_term_meta_cache
There are already plugins out there that do most or all of this.“

Boone Gorges im #core-Slack-Channel

Boone Gorges im #core-Slack-Channel

Einen detaillierteren Entwurf des Ablaufs hat Boone auf Make/Core veröffentlicht.

Er sieht in Verbindung mit Plugins, die bereits Meta-Informationen für Taxonomie-Terme ermöglichen folgende drei Probleme:

1. Term-Meta-Plugins, die eine neue Tabelle desselben Namens nutzen aber ein unterschiedliches Schema
2. Plugins, die eine neue Tabelle mit anderem Namen erstellen aber sie mit $wpdb->termmeta ansprechen
3. Plugins, die Funktionen im globalen Umfeld erstellen

Diese Probleme lassen sich nur umgehen, indem Plugin-Entwickler früh darauf aufmerksam gemacht werden und ihre Plugins entsprechend anpassen können. Einer der nächsten Schritte wird voraussichtlich sein, dass sich jemand oder ein Team Term-Meta-Plugins im Plugin Directory anschaut und die Kompatibilitätsprobleme sammelt.

Taxonomie-Schema

Wie bereits in vorangegangenen Wochenrückblicken angesprochen wurden in WordPress 4.4 die geteilten Taxonomie-Terme in den Datenbanktabellen eliminiert. Damit ist es nicht mehr notwendig, die Tabellen wp_terms und wp_term_taxonomy separat vorzuhalten.

Das wird erst mal so bleiben aber irgendwann werden die beiden zu einer Tabelle zusammengeführt werden (#30262). Eine Zusammenfassung des Meetings von Boone findet ihr auf Make/Core.

Diverses

• Twenty Strixteen gibt es jetzt neben GitHub auch im Theme Directory.
• Dominik Schilling und Sergey Biryukov sind die „Backup-Leads“ für 4.4
• Wöchentliche Bug Scrubs zu 4.4 immer am Freitag um 18 Uhr.
• WordPress Core Weekly

Themes

Diese Woche hat das erste Twenty-Sixteen-Meeting im #core-themes-Slack-Channel stattgefunden. Dabei wurden die offenen Issues im GitHub-Repository besprochen. Das Meeting wird immer am Montag und Freitag um 19 Uhr stattfinden. Genauere Informationen zu dem neuen Theme findet ihr in meinem Artikel:

https://florianbrinkmann.com/1339/twenty-sixteen-das-neue-standard-theme-fuer-wordpress-in-der-kurzvorstellung/

Plugins

Die Themes können bereits auf translate.WordPress.org übersetzt werden und die Plugins ziehen nach. Sie werden phasenweise in GlotPress importiert und die Entwickler eines Plugins werden via E-Mail benachrichtigt, wenn ihr Plugin in der nächsten Rutsche dran ist.

Die Reihenfolge des Imports richtet sich nach der Anzahl der aktiven Installationen. Vermutlich werden nur die aktiven Plugins importiert werden. Aktiv bedeutet, dass das Plugin in den letzten zwei Jahren aktualsiert wurde. Nähere Infos zu diesem Prozess hat Samuel Sidler auf Make/Plugins aufgeschrieben.

Feature Plugins

oEmbed

Das oEmbed-Feature-Plugin ermöglicht es, WordPress-Beiträge in die eigenen Inhalte einzubinden wie beispielsweise ein YouTube-Video: Durch einfaches Einfügen der URL. Pascal Birchler hat auf Make/Core den aktuellen Stand des Plugins vorgestellt. So passt sich das iFrame nun automatisch dem verfügbaren Platz an und es funktioniert nahtlos mit der REST API.

RICG Responsive Images

Das Feature Plugin für die Unterstützung von Responsive Images wurde am Dienstag in Version 2.4.0 veröffentlicht. Damit sollte laut Joe McGill alles für einen Patch-Kandidaten vorhanden sein (#33641). Wenn keine großartigen Probleme mehr auftauchen, wäre das sein Ziel für diese Woche.

Ein weiterer Bestandteil des Plugins soll sein, die Imagick-Einstellungen zur Optimierung hochgeladener Bilder zu verbessern (#33642). Auf GitHub gibt es Performance-Tests zur möglichen Implementierung des Plugins mit dem the_content()-Filter, damit auch alte Beiträge berücksichtigt würden. Aktuell kümmert sich das Plugin nur um neue Beiträge und fügt das Markup beim Einfügen eines Bildes mit in den Editor ein.