Für WordPress ist für dieses Jahr noch ein Sicherheits- und Stabilisierungsrelease vorgesehen. Der Kandidat für die Version 5.0.2 kann bereits getestet werden.
Mit dieser neuen Version seien 26 Bugs im WordPress-Core ausgemerzt worden, heißt es. Mit an Bord ist der Gutenberg-Editor in Version 4.7. Viele Verbesserungen würden dazu beitragen, dass ein Blog mit etwa 200 Blöcken einen Performancegewinn von 330 Prozent erzielen kann, schreibt Mathias Ventura von WordPress.
Der finale Release soll nach aktueller Planung am 19.12.20198 erfolgen. Ansonsten hat WordPress 2019 viel vor. Einige Prioritäten zeichnen sich ab, doch andere Dinge vermisst man in der aktuellen Planung.
Nächste Beta im Januar mit Perfomance-Steigerungen
Für Januar 2018 ist bereits eine Betaversion von WordPress 5.1 angekündigt, die im Februar als finale Version erscheinen soll. WordPress arbeitet an PHP Upgrade Warnungen und einem Schutz vor dem „White Screen of Death“ im Rahmen des neuen Health Check Features, wobei diese Dinge noch „uncommitted“ sind. Es ist unklar, ob diese nützlichen Funktionen noch in WordPress 5.1 dabei sein werden. Die neuen „Warnungen“, man möge doch bitte eine aktuelle PHP-Version einsetzen, sind zunächst nur Hinweise. Für April 2019 allerdings ist vorgesehen, dass WordPress erst aber einer bestimmten Version funktionieren soll.
Um die weiteren Schwerpunkte, die WordPress für die nächste Zeit setzt, geht es auch im goneo Webhosting- und Webmacher Podcast in Episode 60.
Mullenwegs Prios für das kommende Jahr
In einem Beitrag auf make.wordpress.com hat Mitbegründer Matt Mullenweg, der auch weiter die Rolle des Chefentwicklers bei WordPress einnimmt und CEO von Automattic ist, neun Prioritäten formuliert, (die er später dann in „Projekte“ umbenannt hat):
- Navigationsmenüs sollen in einen Block.
- Widgets sollen Blöcke werden.
- Der Bearbeitungsbereich für Widgets in wp-admin/widgets.php und der Customizer sollen Block-fähig werden.
- Mit Themes soll man visuell Contentbereiche festlegen können, die man dann mit Gutenberg ansehen kann.
- Der als Plugin verfügbare „Health Check“ soll in den Core von WordPress integriert werden, also fester Bestandteil jeder Installation sein.
- User sollen die Möglichkeit haben, einzustellen, dass Plugins und Themes automatisch geupdatet werden.
- User sollen eine Möglichkeit bekommen, einzustellen, dass auch tiefgreifendere Core Updates automatisch ausgeführt werden.
- Es soll ein Verzeichnis auf WordPress.org entstehen, in der man Blöcke entdecken und diese einfach installieren kann.
- Es soll ein „Triage-Team“ gebildet werden, das sich um die 6.500 offenen Fehlermeldungen in Trac, dem WordPress-eigenen Bugreport-System, kümmern soll. Nachdem diese Team „Triage-team“ genannt wird, wird es wohl zunächst vorrangig darum gehen, diese Meldungen zu priorisieren.
Datenschutz, Sicherheit und Performance keine Prioritäten?
Offenbar wünschen sich User auch mehr Datenschutzfeatures in künfitgen Versionen, wie die Möglichkeit, vom user generelle Zustimmung zu einer Datenschutzerklärung abzuholen und zu protokollieren, nach Möglichkeit auf externe Ressourcen zu verzichten (viele Elemente holen Javascript- oder CSS-Frameworks aus anderen Quellen) und die De-Integration von alten Services wie Gravatar.
Man darf bezweifeln, dass alle diese Vorhaben im nächsten Jahr wirklich umgesetzt werden. Klar ist jedoch die Fokussierung auf den Block-Ansatz. Viele Bereich sollen sich der Block-Konzeption unterordnen, wie Widgets, Menüs, so dass diese Elemente leichter bearbeitet werden können. Das ermöglicht vielen Usern dann, am Erscheinungsbild selbst Änderungen vorzunehmen, ohne in das Theme Grundgerüst auf Codeebene eingreifen zu müssen.
Nimmt WordPress den Markt für „Homepagebaukästen“ ins Visier?
Diese Do-it-yourself-Herangehensweise kennt man heute eher von proprietären „Homepagebaukästen“, die die Möglichkeit, eine Webseite zu erstellen, so weit irgendwie möglich grafisch umsetzen. In solchen Produkte ist der Block-Ansatz allgegenwärtig. Es scheint, als würde WordPress diesen Markt adressieren wollen.
Eine große Herausforderung, die sich dann stellt, wird sein, die Manipulationsmöglichkeiten so auszubalancieren, dass möglichst „unfallfreie“ Websites entstehen, die ästhetische Standards nicht allzu sehr verletzen. Die User, die Contents erstellen, sind im Regelfall keine Webdesigner – gerade deswegen nutzen sie WordPress.
Interessant wird es auch werden, wie sich die „Verblockung“ mit dem Thema Performance verträgt. Zumindest der Code-Overhead dürfte komplexer und umfangreicher werden. Die einzelnen Blöcke müssen ja verwaltet werden. Bei WordPress im Gutenberg-Editor geschieht dies mit im Text eingebetteten Auszeichnungen, der beim Bearbeiten und Ausspielen interpretiert werden muss. Dies bläht den Code auf.
Andererseits ist diese Herangehensweise eine recht elegante Lösung, da so eine weitgehende Kompatibilität zu alten Beiträgen und Seiteninhalten gegeben ist. Auch wenn man einen kompletten Beitragsinhalt in Codeform herauskopiert, um den Inhalt zum Beispiel mit Notepad++ zu bearbeiten, kann man die Blocksteuerauszeichnungen gut identifizieren. Sie erscheinen wie zu ignorierenden Anmerkungen im Stil von Kommentaren in PHP-Skripten: „<!– (auszeichnung) –>“
Googles Engagement in WordPress: Ist das Site Kit Plugin ein Ergebnis dieser Kooperation?
Eine der wichtigsten Punkte, die Performance, steht bei WordPress aktuell nicht auf der Prioritätenliste.
Viele, auch wir, gingen davon aus, dass die Entwickler, die Google zu WordPress dediziert hat, daran arbeiten würden, nach Performanceverbesserungen zu suchen. Statt dessen sahen wir kürzlich ein von Google herausgegebenes Plugin, mit der Google die Dienste Search Console, Adsense, PageSpeed Insights und Analytics einbringt. Hier der originale Blogbeitrag von Google zu Site Kit, wie sich das Plugin nennt. Getestet werden kann es als Beta „in earyl 2019“, wie es in dem Beitrag heißt. Wer an der Beta interessiert ist, kann sich schon registrieren.