Zielgerichtete Unterstützung von PHP für zukünftige WordPress-Versionen gewünscht

Juliette Reinders Folmer veröffentlichte einen Vorschlag für WordPress, die Unterstützung für alte PHP-Versionen nach einem festgelegten Zeitplan einzustellen. Sie schrieb den Vorschlag, nachdem Matt Mullenweg, Mitbegründer und Projektleiter von WordPress, sich um Lösungen bemüht hatte. Dies geschah, nachdem er letzte Woche ein Trac-Ticket geschlossen hatte, das darauf abzielte, die Unterstützung für PHP 5.6 aufzugeben und die Mindestversion auf 7.1 zu erhöhen. Und dies bereits für WordPress 5.6, welches im Dezember erwartet wird.

Ich finde den Vorschlag richtig gut. Und wahrscheinlich werden viele in der WordPress-Community dahinterstehen. Es handelt sich um einen klar umrissenen, transparenten Weg für die zukünftige PHP-Unterstützung von WordPress als Plattform.

Zwei Vorschläge

Folmer legte in dem Vorschlag im wesentlichen zwei Roadmaps vor. Der erste Vorschlag entscheidet, zu welchem Zeitpunkt WordPress die Unterstützung für eine bestimmte PHP-Version einstellen würde. Demnach würde jedes Jahr im Dezember die Unterstützung für eine mehr als fünf Jahre alte PHP-Minor-Version enden. Das würde auch mit der bevorstehenden Hauptversion von WordPress zusammenfallen. Hier der Zeitplan:

  • Dezember 2020 – PHP 7.1
  • Dezember 2021 – PHP 7.2
  • Dezember 2022 – PHP 7.3
  • Dezember 2023 – PHP 7.4
  • Dezember 2024 – PHP 8.0

Der zweite Teil des Vorschlags schafft einen gleitenden Zeitplan für die Rückportierung von Sicherheitsupdates nach WordPress. Gegenwärtig veröffentlicht WordPress Sicherheitsupdates bis zurück zur Version 3.7. Im Falle des oben genannten Zeitplans würde Folmers Empfehlung nur die WordPress-Veröffentlichungen der letzten vier Jahre Sicherheitsupdates erhalten.

Eine solche Änderung würde bedeuten, dass das WordPress-Projekt bei der Veröffentlichung von WordPress 5.6 im Dezember 2020 verpflichtet wäre, Sicherheitsaktualisierungen bis zu WordPress 4.7, welches im Dezember 2016 veröffentlicht wurde, zu liefern.

Folmer schlägt außerdem vor, PHP-Upgrade-Meldungen vom Site Health Project auf die derzeit unterstützten älteren Versionen von WordPress auszudehnen. Diese Maßnahme würde Benutzer über Probleme mit der PHP-Version informieren, bevor sie den Sprung zu einer neueren Version von WordPress machen.

9 Jahre zeit für ein Update

Beide Vorschläge zusammen gäbe den Benutzern ein potenzielles Zeitfenster von neun Jahren, in dem sie auf der alten PHP-Version bleiben könnten. Neun Jahre sind im Web eine halbe Ewigkeit. Wer weiß schon, was in knapp 10 Jahren sein wird? Heutzutage ändert sich der Technik-Stack fast schon halbjährlich.

Nichts desto trotz ist der Plan sehr gut und wohlüberlegt. Zum einen könnten mehr Entwickler “zurück” zu WordPress finden (zur Erinnerung: In der alljährlichen StackOverflow-Umfrage landet WordPress regelmäßig auf dem letzten Platz) und zum anderen müsste die Rückwärtskompatibilität nicht so lange aufrecht erhalten werden.

Ein fester Zeitplan für den Versionswechsel ist willkommen. Er bringt alle, von den Entwicklern über die Endbenutzer bis hin zu den Webhosts, auf die gleiche Seite. Dieses Maß an Transparenz ist notwendig, wenn WordPress jemals die Absicht hat, voranzukommen, ohne die ständige Diskussion über PHP wieder anzuheizen.

Matt hatte im Trac-Ticket von letzter Woche geschrieben, es sei besser abzuwarten bis bestimmte Nutzungsdaten von PHP unter eine bestimmte Schwelle fallen. Aber das System des Abwartens macht die Sache nur noch komplizierter. Ein konkreter Plan muss her. Und das, so denke ich, hat Folmer geschafft. Letztlich wollen alle das Gleiche – das gesamte Projekt vorantreiben und moderne Werkzeuge einsetzen ohne dass am Ende zu viele Nutzer zurückgelassen werden.

Mir gefällt die Aussage von WPTavern: “WordPress muss klare Erwartungen setzen.”. Es ist mittlerweile so groß und hat so viel Macht: Zeit, dass sie eingesetzt wird.