WordPress-Wochenrückblick KW27: Dev-Posts zu 4.6 und mehr

Die zweite Beta zu WordPress 4.6 wurde ebenso veröffentlicht wie eine ganze Reihe an Dev-Posts zu Neuerungen in 4.6.

Accessibility

Verschiedenes

Core

WordPress 4.6 Beta 2

Am 6. Juli wurde die zweite Beta-Version von WordPress 4.6 veröffentlicht. Was sich seit der ersten Beta getan hat, könnt ihr im Beitrag auf de.wordpress.org nachlesen.

Dev-Notes zu 4.6

Customizer-APIs für Setting-Validation und Benachrichtigungen

Wie bereits in einem früheren Wochenrückblick erklärt, gibt es bei der Validierung von Einstellungen im Customizer einige Mängel. So werden ungültige Werte beim Speichern einfach verworfen, ohne den Nutzer darüber zu informieren. Die neuen APIs für die Validierung beheben dieses Problem und bringen folgende Verbesserungen:

  1. Alle geänderten Einstellungen werden validiert, bevor irgendeine davon gespeichert wird.
  2. Ist eine Einstellung ungültig, wird die Anfrage zur Speicherung zurückgewiesen (die Veränderungen bleiben aber natürlich in den Customizer-Feldern erhalten).
  3. Es werden entsprechende Fehlermeldungen ausgegeben, damit der Nutzer die Fehler beheben kann, bevor er es erneut versucht.

Validierungsverhalten

Wenn das Speichern wegen ungültigen Einstellungen zurückgewiesen wird, werden Fehlermeldungen direkt bei den Einstellungen angezeigt. Nach erfolglosem Speichern wird der Fokus im Customizer auf eine dieser Einstellungen gesetzt – wenn im gerade geöffneten Bereich ein Fehler ist, wird der fokussiert, ansonsten wird ein anderer Bereich mit einem Fehler geöffnet.

Die Validierung geschieht nicht nur beim Speichern, sondern immer, wenn die Vorschau komplett oder via Selective-Refresh aktualisiert wird. Das ist wichtig, damit Nutzer direkt Rückmeldung bekommen, wenn etwas in der Vorschau nicht so angezeigt wird, wie erwartet.

Einige Infos mehr für Entwickler, auch zur neuen Benachrichtigungs-API, gibt es im Beitrag von Weston Ruter auf Make/Core.

API-Änderungen im Customizer

Zusätzlich zu den oben angerissenen Änderungen wurden ein paar weitere Dinge angepasst. So wurde das Markup der Core-Medien-Controls im Customizer vereinfacht, sodass nicht mehr für jede Sub-Control von WP_Customize_Media_Control ein eigener CSS-Selektor notwendig ist. Der CSS-Code wurde komplett refaktoriert. Da sowohl Markup als auch Styling deutlich verändert wurden, solltet ihr eigene Controls, CSS und JavaScript testen, das sich auf Media-Controls im Customizer bezieht (#30618).

Darüber hinaus bekommt der customize_value_{$id_base}-Filter nun als zweiten Parameter mit $this die WP_Customize_Setting-Instanz übergeben, mit der ihr auf alle Methoden und Parameter der spezifischen Einstellung zugreifen könnt (#36452).

Weitere Änderungen könnt ihr im Beitrag von Nick Halsey nachlesen – unter anderem kann der aktuell ausgeklappte Bereich nun über die Esc-Taste geschlossen werden.

Vor-instanziierte Widget-Registrierung

register_widget() und unregister_widget() erlauben jetzt als Parameter auch ein Objekt einer WP_Widget-Unterklasse. Vorher musste der Klassenname übergeben werden (#28216). So können nun beispielsweise dynamisch Widget-Typen hinzugefügt werden, etwa ein Neueste-Beiträge-Widget für jedes Post-Format. Ein paar weitere Infos gibts im Beitrag von Weston.

Lokalisierung des Datepickers

In 4.6 wird der Datepicker von jQuery UI mit lokalisierten Standard-Strings ausgestattet. Das bedeutet, ab 4.6 kann der Datepicker einfach eingebunden werden, ohne sich um die Übersetzung in andere Sprachen als Englisch kümmern zu müssen.  Im Beitrag von Torsten Landsiedel gibt es ein paar nähere Infos sowie eine Liste der Plugins, die auf diese neue Standard-Lösung wechseln könnten.

Verbesserungen der Internationalisierung

Mit WordPress 4.6 werden Plugin- und Theme-Übersetzungen zuerst im wp-content/languages-Verzeichnis gesucht, wo die Sprachpakete von translate.wordpress.org gespeichert sind (r37414). Im Zuge dieser Änderung muss nun auch nicht mehr die Funktion zum Laden der Text-Domain aufgerufen werden (load_plugin_textdomain(), load_theme_textdomain() und load_muplugin_textdomain()). Diese Änderungen können überschrieben werden. Wie das geht, und was sich noch im Bereich Internationalisierung geändert hat, lest ihr im Beitrag von Pascal Birchler.

WP_Term_Query

In 4.6 wird die Klasse WP_Term_Query eingeführt. Die get_terms()-Funktion wurde in einen Wrapper für die neue Klasse umgewandelt – außer der Unterstützung, nun auch Terms nach der term_taxonomy_id abzufragen, gab es keine Funktionsänderungen bei get_terms(). Ein paar weitere Infos gibts im Post von Boone Gorges.

Bootstrap-Updates in 4.6

Immer, wenn WordPress geladen wird, geht es durch den Bootstrap- oder Lade-Prozess. In 4.6 wurden ein paar Änderungen vorgenommen, die auf die Mehrzahl der WordPress-Sites keine Auswirkungen haben sollten. Wenn ihr aber eine eigene advanced-cache.php habt, große Profil-Sites betreibt oder an Tools arbeitet, die was am Bootstrap-Prozess machen, solltet ihr euch den Beitrag von Aaron Jorbin durchlesen.

Unter anderem wird die plugin.php früher in der wp-settings.php geladen. Die Datei enthält beispielsweise die add_action()- und add_filter()-Funktionen. Durch das frühere Laden können einige Hooks früher ausgeführt werden, und ein advanced-cache.php-Drop-In die Plugin-API nutzen, ohne direkt globale Variablen manipulieren zu müssen. Daneben ist die Funktion is_ssl() nun in der wp-includes/load.php zu finden. Alles weitere dazu im oben verlinkten Beitrag.

Resource-Hints

In 4.6 wird eine einfache API eingeführt, mit der für link-Tags das rel-Attribut mit dns-prefetch, preconnect, prefetch oder prerender gefüllt werden kann, damit dem Browser bei der Entscheidung geholfen werden kann, welche Ressourcen wie geladen werden sollen. Mehr Informationen dazu, inklusive Links zu der W3C-Spezifikation, gibt es im Beitrag von Pascal.

Shiny-Updates

Wie bereits mehrach erwähnt, wird der Vorgang von Plugin/Theme-Installation, -Deaktivierung und -Löschung verändert. Dabei wird keine neue Seite mehr geladen, womit das ganze (mindestens gefühlt) schneller abläuft. Weiteres dazu und zu den damit einhergehenden Änderungen unter der Haube gibts im Post von Pascal.

Native Fonts im Backend

In 4.6 wird die mit WordPress 3.8 eingeführte Nutzung von Open Sans als Backend-Font beendet. Stattdessen werden System-Fonts genutzt, was unter anderem eine Verbesserung der Performance mit sich bringt (#36753). Details dazu und den Font-Stack, der nun genutzt wird, findet ihr im Beitrag von Matt Miklic.

Verbesserungen an register_meta()

In 4.6 wird die register_meta()-Funktion dahingehend erweitert, dass sie die Registrierung von Meta-Keys ermöglicht und was von diesen Keys erwartet werden kann. Die Registrierung von Daten wird im globalen Bereich gespeichert, womit Metadaten eines Objekts erreichbarer für Teile des Cores und erweiternden Code sind.

In 4.5 und früher war es nicht möglich, den öffentlichen Status eines Meta-Keys zu definieren. Einige Informationen mehr zu dieser Änderung gibt es im Post von Jeremy Felt.

Multisite-fokussierte Änderungen

WordPress 4.6 führt die Klassen WP_Site_Query und WP_Network_Query sowie deren Companion-Funktionen get_sites() und get_networks() ein. Mit WP_Site_Query beziehungsweise get_sites() können Blogs nun auf flexible Art aus der $wpdb->blogs-Tabelle anhand der id, domain, path und mehr abgerufen werden. Zudem wurden neue Filter wie parse_site_query, pre_get_sites und the_sites hinzugefügt.

Mit WP_Network_Query beziehungsweise get_networks() können Netzwerke via id, domain und path aus der $wpdb->site-Tabelle geholt werden. Auch hier wurden neue Filter spendiert.

Daneben gibt es Verbesserungen an WP_Site und WP_Network sowie insgesamt neue Actions und Filters. Wer mehr erfahren möchte, wird im Beitrag von Jeremy fündig.

Verschiedenes

Polyglots

Verschiedenes

Design

Verschiedenes

Docs

Verschiedenes

  • HelpHub-Chat. Beispielsweise wird überlegt, wie man vom HelpHub auf übersetzte Codex-Artikel verweisen kann, bis die Möglichkeit der Übersetzbarkeit im HelpHub gegeben ist.

Plugins

Inhalte nicht von anderen Domains laden

Bilder, Skripte, CSS, et cetera sollten in Plugins lokal geladen werden. Ausnahme davon sind Services, die externe Kommunikation benötigen. Ist das nicht der Fall, gibt es keinen Grund, Daten von einem anderen Server zu laden als dem, auf dem das Plugin installiert ist. Etwas ausführlichere Gedanken zu dem Thema gibts im Text von Mika Epstein auf Make/Plugins.

Marketing

„The Four Horsemen of WordPress.org Marketing“

Beim Contributor-Day des WCEU haben sich vier Untergruppen für das WordPress-Marketing-Team herauskristallisiert:

  • Marketing für Entwickler. Hier geht es darum, entwicklungs-bezogene Informationen bereitzustellen, etwa technische Anwendungsfälle und Beispiele, Best-Practices und so fort.
  • Marketing für Agenturen und Kunden. Diese Gruppe fokussiert sich darauf, Materialien zu erstellen, die hilfreich für Agenturen sind, um es für die Arbeit mit Kunden zu nutzen. Darüber hinaus sollen auch Infos für größere Unternehmen erstellt werden, wo die Entscheidung für eine Plattform innerhalb der Firma getroffen wird.
  • Marketing für Endnutzer. Hier wird an Informationen über Usability, Funktionen und Integrationen von WordPress gearbeitet, um Endnutzern zu helfen, ihre Site selbst zu verwalten. Zudem werden Informationen bereitgestellt, die WordPress mit anderen Lösungen vergleichen.
  • Die Community selbst vermarkten. Die Gruppe glaubt, dass die Community selbst ein großer Pluspunkt für WordPress ist. Dinge sichtbarer zu machen, die aus der Community kommen, würden positive Effekte haben.

Mehr Informationen gibt es im Beitrag von Sara Rosso auf Make/Marketing. Dort könnt ihr euch auch melden, wenn ihr an einer bestimmten Untergruppe interessiert seid.

Das könnte auch interessant sein

Schreib einen Kommentar

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