PHP 8.2: Was bedeutet es für WordPress, Plugins und Entwickler?

Veröffentlicht: 2022-12-14

PHP 8.2.0 feierte sein Debüt am 8. Dezember 2022. Als großes Update bringt es Leistungsverbesserungen, eine einfachere Syntax und eine größere Typsicherheit mit null , false und true als eigenständige Typen. Eine der größten Änderungen, die WordPress-Entwickler wahrscheinlich herausfordern wird, ist die Einführung von schreibgeschützten Klassen, die dynamische Eigenschaften nicht zulassen.

Dynamische Eigenschaften sind veraltet und führen in PHP 9 oder möglicherweise PHP 10 zu einem fatalen Fehler. Obwohl potenziell schmerzhaft – insbesondere für den WordPress-Kern – ist die Ablehnung eine Schlüsselfunktion und ein Geschenk für Entwickler von PHP.

Werfen wir einen Blick auf die jüngste Entwicklung von PHP und auch darauf, wie WordPress-Entwickler die Abwärtskompatibilität aufrechterhalten und gleichzeitig neue Funktionen nutzen, wenn sie den Endbenutzern am meisten nützen.

Mit der PHP-Entwicklung in WordPress Schritt halten

Da der WordPress-Kern eine erhebliche Abwärtskompatibilität ohne geplante End-of-Life-Daten beibehält, wenn alte Versionen nicht mehr unterstützt werden, ist es Aufgabe von WordPress-Unternehmen, ihren eigenen Produkt- oder Servicelebenszyklus und die von ihnen unterstützten PHP-Versionen zu bestimmen.

Im Gegensatz zu WooCommerce, das mindestens PHP 7.4 erfordert, empfiehlt WordPress Core derzeit nur PHP 7.4 oder höher. Es „funktioniert auch mit“ PHP 5.6.20, das Ende 2018 sein End-of-Life-Datum erreichte. Das WordPress-Projekt stellt dies fest und warnt davor, dass die Verwendung nicht unterstützter PHP-Versionen „Ihre Website Sicherheitslücken aussetzen kann“. (WordPress.org-Anforderungen)

Glücklicherweise verwenden derzeit nur 5,1 % aller WordPress-Sites PHP 5.6 und nur 2 % eine noch ältere Version. 20 % verwenden PHP 7.0 bis 7.3, und die größte Gruppe (56,7 %) verwendet PHP 7.4. (WordPress.org-Statistik)

Leider hat PHP 7.4 Ende November 2022 gerade sein EOL-Datum erreicht. PHP 8.0 hat weniger als ein Jahr Zeit für seine offizielle Sicherheitsunterstützung bis zum größten Teil des Jahres 2023. Die aktuelle und aktiv unterstützte Version, PHP 8.1, wird am Ende veraltet sein von 2024. PHP 8.2, das gerade seine erste stabile Version hatte, wird bis Dezember 2025 Sicherheitsunterstützung haben.

Dies ist ein schneller Veröffentlichungszyklus, und es ist keine Überraschung, dass das WordPress-Ökosystem Schwierigkeiten hat, damit Schritt zu halten. Da mehr als die Hälfte des Webs auf WordPress läuft, ist es ein großes Schiff, das sich nicht schnell drehen kann. Es ist viel mehr ein Balanceakt als ein Wettlauf an die Spitze. Der Wechsel zu PHP 8 bietet jedoch viele Vorteile mit großen leistungssteigernden Funktionen wie Just-in-Time (JIT) PHP-Kompilierung zur Laufzeit für eine schnellere Ausführung mit weniger Speicherverbrauch.

Der Kompromiss zwischen Abwärtskompatibilität und Stabilität, Vorwärtsdenken und Innovation

Der Kompromiss zwischen der Versorgung der größtmöglichen Benutzergruppe und der Aufrechterhaltung der Aktualität mit PHP war schon immer ein Dilemma für WordPress-Entwickler, Hosts und Produktunternehmen. Agenturen und Freiberufler mit langjährigen Kunden und alten Websites stehen vor dem gleichen Problem: Die Aktualisierung der Mindestanforderungen kann bestehende Kunden dazu zwingen, erhebliche Änderungen an ihren Websites vorzunehmen, oder sie sehen, dass sie kaputt gehen.

Auf der einen Seite sind die Vorteile, mit PHP auf dem neuesten Stand zu bleiben, verbesserte Sicherheit und Leistung sowie die neuesten Programmierkonzepte und -funktionen für Entwickler. Auf der anderen Seite ist der Hauptvorteil der Verzögerung des mindestens erforderlichen PHP eine glückliche (wenn auch selbstzufriedene) und breite Kundenbasis. Es ist eine „bezahle mich jetzt oder bezahle mich später“-Situation. Irgendwann muss man das Pflaster abreißen.

Gute Daten und Telemetrie über Benutzerumgebungen können dabei helfen, die am wenigsten störende Zeit zu bestimmen, um eine Mindestanforderung für die PHP-Version zu erhöhen. Die meisten Plug-in-Entwickler behalten diese Zahlen mit ihren eigenen Tools im Auge, da sie nicht Teil der aktiven Installationsdaten des WordPress.org-Plug-in-Repositorys sind. Unweigerlich führt jede möglicherweise bahnbrechende Änderung, die viele Menschen betrifft, garantiert zu einer Flut von Support-Tickets.

Die Priorisierung der Abwärtskompatibilität ist auch mit einem hohen Wartungsaufwand verbunden. Die Unterstützung einer sehr großen und vielfältigen Benutzerbasis ist für den Endbenutzer großartig, bedeutet jedoch, dass Entwickler ihren Code mit vielen verschiedenen Umgebungen arbeiten müssen. „Ich liebe es, ältere PHP-Versionen zu unterstützen, wenn neue Funktionen hinzugefügt werden“, sagte noch nie ein Entwickler!

Sie müssen sich nicht nur um veraltetes PHP kümmern, sondern auch um veraltete Datenbanken und Dutzende anderer Variationen im WordPress-Stack. Grenzfälle tauchen auf und verwirren sogar die Experten, wenn es ein breites Spektrum an WordPress-Serverumgebungen mit veralteten Elementen gibt.

Der beste Zeitpunkt, um Ihre PHP-Mindestanforderungen zu erhöhen

Die Veröffentlichung von iThemes Security Pro 7.2 ist ein gutes Beispiel für die Anhebung der PHP-Mindestanforderungen eines WordPress-Produkts, um sowohl Innovation als auch Stabilität für bestehende Kunden zu bieten.

Ab Version 7.2 erfordert iThemes Security Pro PHP 7.3 oder höher und unterstützt bis zu 8.1. Die Entscheidung, die PHP-Anforderung für iThemes Security Pro zu aktualisieren, wurde getroffen, um das WebAuthn-Framework zu implementieren. Die Implementierung erforderte Bibliotheken, die PHP 7.3+ benötigen, um Verschlüsselung und öffentliche Schlüssel zu verwalten. Die in iThemes Security Pro 7.2 eingeführten 2FA-, Passkey- und biometrischen Anmeldefunktionen sind ein direktes Ergebnis dieser Entscheidung. Zu einer Zeit, als seine klaren Passwörter gebrochen wurden, brachte das iThemes-Sicherheitsteam zum ersten Mal die passwortlose Anmeldung bei WordPress als primäre Benutzerauthentifizierungserfahrung.

Es wäre möglich gewesen, diese Funktionen durch Umschreiben der WebAuthn-Bibliotheken für die Kompatibilität mit älteren PHP-Versionen zu erstellen. Das würde natürlich viel mehr Arbeit bedeuten und zusätzlichen zu wartenden Code erzeugen. Klüger war es, mit der PHP-Community in moderatem Tempo Schritt zu halten, indem Abhängigkeiten übernommen wurden, die PHP 7.3 oder höher erfordern. Die meisten ihrer Benutzer waren bereits dort. Aus diesem Grund hat das Entwicklerteam von iThemes Security beschlossen, die PHP-Mindestanforderungen für neue und bestehende Benutzer zu erhöhen.

Für WordPress-Produkte, die stark in den Gutenberg-Blockeditor investiert sind, wie GiveWP, kann die Verwaltung von Änderungen noch schwieriger sein. Die Stabilität und langsame Änderungsrate im WordPress-Kern mag für Backend-PHP-Entwickler frustrierend sein, aber es ermöglicht Frontend-JavaScript/React-Entwicklern, die Plattform voranzutreiben.

Jason Adams, Entwicklungsleiter bei GiveWP, merkt an, dass sie nicht abwärtskompatibel sein müssen, da sie Benutzer zwischen Versionen migrieren können, wenn sich der Site-Editor weiterentwickelt. „So etwas wie eine Migration für PHP gibt es nicht“, kommentierte er. Letztendlich müssen sie sich an die PHP 9-Architektur anpassen und weg von den neu veralteten Funktionen in PHP 8.2.

Es gibt keinen „richtigen Zeitpunkt“ für jedes Produkt im gesamten WordPress-Ökosystem, um die PHP-Mindestanforderungen zu aktualisieren. „Es ist kein Problem, das man philosophisch lösen kann“, sagte Adams zu mir. Es hängt wirklich von einer Einschätzung ab, wie viele Benutzer von der Änderung betroffen sein werden. Wenn 90 % oder mehr PHP 7.2 oder 7.4 verwenden, ist eine Anhebung der Mindestanforderung auf dieses Niveau praktikabel.

Diese Zahlen können je nach spezifischer Benutzerbasis eines Produkts stark variieren, sagt Adams. Ein Produkt, das von technisch versierteren Kunden verwendet wird, ist tendenziell näher an den derzeit unterstützten PHP-Versionen. Ein Produkt wie GiveWP, das von vielen gemeinnützigen Organisationen verwendet wird, muss mehr Gewicht auf die Abwärtskompatibilität legen. Ein weiterer Weg nach vorne besteht darin, Legacy-Code und seine Benutzer in einer langfristigen Version abzweigen zu lassen, die unterstützt wird, aber keine neuen Funktionen hinzugefügt werden. Wenn Benutzer bereit sind, das Upgrade durchzuführen, können sie auf eine neue Hauptversion migrieren, die für zukünftige PHP-Kompatibilität entwickelt wurde.

Verfallshinweise treiben die Entwicklung voran

WordPress.com hat gerade PHP 8.2 als Option für seine Business- und E-Commerce-Pläne mit aktivierten Hosting-Funktionen eingeführt, und im WordPress.org-Ökosystem ist es unwahrscheinlich, dass einigermaßen ausgereifter älterer Code mit der nächsten großen PHP-Version kaputt geht oder unsicher wird Veröffentlichung. Obwohl die Kern-Codebasis von WordPress.org offiziell nur „Beta“-Unterstützung für PHP 8.0 bietet, funktioniert sie im Allgemeinen gut mit den neuesten Versionen von PHP, ebenso wie gut unterstützte Plugins. Sie werden keine schwerwiegenden oder Analysefehler werfen. Sie sollten nicht einmal viele Warnungen sehen, wenn das Debugging aktiviert ist. Möglicherweise sehen Sie viele Hinweise auf veraltete Funktionen, die keine Fehler sind – noch nicht.

Die Frustrationen eines schnellen PHP-Release-Zyklus haben viel damit zu tun, dass Entwickler sich im Unkraut beim Refactoring ihres Codes verzetteln und veraltete Aspekte von PHP aufholen. Diese kritische Arbeit lässt ihnen möglicherweise weniger Zeit, um neue Konzepte und Funktionen zu erkunden und zu erneuern, die die neueste PHP-Version mit sich bringt.

Es gibt eine andere Möglichkeit, diese Situation zu betrachten. Der Umgang mit veralteten Funktionen von PHP ist tatsächlich zukunftsweisend und zwingt Entwickler, die nächsten Iterationen einer sich entwickelnden Sprache fließend zu beherrschen. Ohne diese etwas erzwungene Übung würde sich vorhandenes Wissen leichter in alte Gewohnheiten einleben, die schlecht werden, wenn sie veraltet sind.

Veraltungshinweise weisen auf Dinge hin, die jetzt funktionieren, aber in zukünftigen Versionen von PHP kaputt gehen werden. Das ist gut für Sie, wenn Sie ein Entwickler sind, wie Brent Roose erklärt. Wenn Entwickler diese Hinweise beachten, haben sie genügend Zeit, sich über veralteten Code zu informieren. Und es sollte kein Hindernis für kleinere Versionsaktualisierungen sein.

Timothy Jacobs, iThemes Security Lead Developer und WordPress Core Committer, sagt, dass es gut ist, Verfallswarnungen zu haben. Sie drängen Entwickler dazu, „korrekteren“ und „weniger anfälligen“ Code zu akzeptieren, der immer sicherer, leistungsfähiger, fehlerfreier und besser in der Lage ist, Grenzfälle zu bewältigen. In dieser Ansicht sind E_DEPRECATED-Meldungen, die Ihr Fehlerprotokoll füllen, „wie ein Frühwarnsystem, dass Dinge in der Zukunft kaputt gehen werden, aber sie sind jetzt nicht kaputt.“

Verzicht auf dynamische Eigenschaften nach PHP 8.2

Nikita Popovs Begründung für die schrittweise Abschaffung dynamischer Eigenschaften in PHP 9 ist ein gutes Beispiel für den evolutionären Drang von PHP zu widerstandsfähigerem Code und Programmierkonventionen:

Die Motivation für diese Änderung ist zweierlei: Um Fehler (aufgrund von Tippfehlern oder Umbenennungen) im allgemeinen Fall zu vermeiden und um beabsichtigte Verwendungen explizit zu machen. Das Kernproblem besteht darin, dass das Lesen aus einer nicht vorhandenen Eigenschaft eine Diagnose ausgibt, die das Problem sofort deutlich macht, während das Schreiben in eine nicht vorhandene Eigenschaft völlig geräuschlos erfolgt. PHP gibt keinerlei Hinweis darauf, dass der Programmierer einen Fehler gemacht hat.

Brent Rooses zweiminütiges Video über die Entwicklung von PHP 5.6 zu 8.2 ist eine brillante und einfache visuelle Illustration, wie weit PHP von 2014 bis heute gekommen ist. Am Beispiel eines einfachen Datentransferobjekts zeigt Roose, wie der Code von PHP 5.6 auf dem Weg zu PHP 8.2 dramatisch zu einem deutlich einfacheren, schlankeren und insgesamt eleganteren Codeblock schrumpft.

Wie Roose in seinen Tipps zum Umgang mit dynamischen Eigenschaften (die in PHP 8.2 veraltet sind) anmerkt, sollten Entwickler genügend Spielraum haben, um ihren vorhandenen Code zu aktualisieren, bevor Warnungen wegen Ablehnung zu schwerwiegenden Fehlern werden. Diese Landebahn wird jedoch schnell abnehmen, und WordPress ist ein Sonderfall. Tonya Mork hat einen akzeptierten Vorschlag in Trac zum Umgang mit der Ablehnung unbekannter dynamischer Eigenschaften im WordPress-Kern. Sie und Juliette Reinders Folmer befürchten, dass WordPress-Entwickler nicht genug Zeit haben werden, ihren Code zu überarbeiten, ganz zu schweigen von den besonderen Herausforderungen, die die Aufrechterhaltung der Aufwärtskompatibilität für ein zwanzig Jahre altes Projekt mit sich bringt. Mork, Reinders Folmer und Sergey Biryukov waren die weitgehend unbesungenen Helden dieser gewaltigen Aufgabe.

In ihrer Diskussion über dynamische Eigenschaften und magische Methoden in PHP 8.2 weisen Mork und Reinders Folmer darauf hin, dass die Wurzeln von WordPress in PHP 3 und 4 es in einem soliden prozeduralen Programmieruniversum halten, während PHP als objektorientierte Sprache weiter voranschreitet. Core-Entwickler müssen einen Weg finden, das Verhalten des Legacy-Codes im heutigen PHP beizubehalten, ohne die Abwärtskompatibilität zu beeinträchtigen, „und den Code trotzdem besser und sicherer zu machen und die Abwertung dynamischer Eigenschaften von PHP 8.2 abzumildern“, wie Reinders Folmer es ausdrückt. „Wir machen uns tatsächlich das Leben sehr schwer mit [dem WordPress-Kern] keine [Abwärtskompatibilitäts-] Bruchregel“, bemerkt sie in dem Video.

„Dafür gibt es einen guten Grund“, antwortet Mork – „es ist für Benutzer. Die Benutzer können darauf vertrauen, dass sie diesen Knopf drücken und ein Upgrade durchführen können, und dass wir über Abwärtskompatibilität nachgedacht haben, dass wir ihr Priorität eingeräumt haben. Es ist ein Eckpfeiler für uns … damit die Benutzer sicher sein können, ein Upgrade durchzuführen.“

Alle Entwicklung ist Wartung…

Es ist eine einzigartige Herausforderung, zu versuchen, „modernes“ PHP zurückzuportieren, damit es mit den beiden vorherigen Hauptversionen von PHP funktioniert, um die Abwärtskompatibilität im WordPress-Kern aufrechtzuerhalten. Plugin-Entwickler haben eine viel einfachere Aufgabe, ihren Code so zu aktualisieren, dass neue Funktionen wie die schreibgeschützten Klassen von PHP 8.2 und die Einstellung dynamischer Eigenschaften genutzt werden können. Ein Großteil dieser Arbeit ist größtenteils auch eine Form der Wartung.

Architektonisch konzentrieren sich die Änderungen von PHP 8+ auf Programmierkonzepte wie Unveränderlichkeit. Unveränderliche Datenstrukturen „beheben nicht von Natur aus Sicherheitsprobleme“, aber sie helfen dem Code von Entwicklern, weniger fehleranfällig und korrekter zu sein, so Jacobs:

Ich würde nicht sagen, dass eine unveränderliche Datenstruktur von Haus aus sicher ist und eine veränderliche Datenstruktur unsicher ist. Vielmehr können unveränderliche Datenstrukturen helfen, Programmierfehler zu beseitigen, die zu Sicherheitsproblemen führen können. Indem wir die Anzahl der verschiedenen Zustände reduzieren, in denen unser Code existieren kann, können wir die Komplexität unseres Codes reduzieren und somit die Wahrscheinlichkeit, Fehler zu machen, verringern.

Der beste Grund, Code auf dem Standard von aktiv unterstützten PHP-Versionen zu halten, ist die Verringerung des Sicherheitsrisikos. PHP 8.2 bringt aus Adams Sicht hilfreiche Annehmlichkeiten und „Leitplanken“, aber wenig, was Programmierer begeistern oder als Game Changer angesehen werden könnte. So etwas wie das Attribut #[\SensitiveParameter] könnte von praktischerer Bedeutung sein, da es das Herausfiltern vertraulicher Daten aus Stack-Traces ermöglicht, die häufig an Dienste von Drittanbietern gehen. Die in PHP 8 eingeführten Attribute sind Adams' Wahl für die letzte Innovation, die ihm aufgefallen ist, weil sie etwas ermöglicht hat, was Sie vorher nicht tun konnten: „Beschreiben Sie etwas [wie Klassen, Variablen, Methoden usw.] aus einer Meta-Perspektive.“

Die Nutzung neuer Funktionen in PHP 8.0 bis 8.2 und zukünftigen Versionen ist der Bereich, in dem die Kreativität der Entwickler glänzen kann, aber es ist sowohl praktisch als auch wichtig, diese Versionen einfach zu unterstützen, damit Plugins und der WordPress-Kern nicht kaputt gehen.

…Und alle Wartung ist Kunst

Jeff Atwood hat einen alten, aber herausragenden Blogbeitrag mit dem Titel „The Noble Art of Maintenance Programming“, den ich kürzlich dank Kale Davis' Hacker Newsletter gelesen habe. „Wartungsprogrammierung wird weithin als Hausmeisterarbeit angesehen“, schreibt Atwood. Das erinnerte mich an die Künstlerin Mirele Laderman Ukeles, deren „Maintenance Art Manifesto“ mir schon immer als sehr relevant für die Programmierung und Webentwicklung erschien:

Zwei grundlegende Systeme: Entwicklung und Wartung. Die Sauerei jeder Revolution: Wer holt nach der Revolution am Montagmorgen den Müll ab? […] Entwicklungssysteme sind partielle Feedbacksysteme mit großem Veränderungsspielraum. Wartungssysteme sind direkte Feedbacksysteme mit wenig Spielraum für Veränderungen.

Laderman Ukeles war eine junge Künstlerin und frischgebackene Mutter im Jahr 1969, als sie das Manifest schrieb und erklärte, Maintenance is Art. Sie war frustriert darüber, wie hochmoderne Kunstwerke und hochrangige Arbeitskräfte von der Arbeit getrennt werden, die sie möglich macht: Elternschaft, Vermittlung künstlerischer Fähigkeiten und Traditionen oder einfach nur das Veranstalten einer Kunstausstellung. Sie hat eine denkwürdige Ausstellung gemacht, die sich um ihre Rolle als Museumshausmeisterin drehte. Dann verbrachte sie den größten Teil ihrer (laufenden) Karriere als Artist-in-Residence des New York City Department of Sanitation. Ihr erstes Projekt in dieser Rolle bestand darin, allen 8.500 Sanitärarbeitern persönlich zu danken, „dass sie New York am Leben erhalten“.

Atwood hat eine ähnliche Einstellung zur Programmierung. Er zitiert mehrere bedeutende Persönlichkeiten der Softwareentwicklung, die sagen, dass die Verunglimpfung von Wartungsarbeiten völlig falsch ist. Robert L. Glass meinte, „Instandhaltung ist eine bedeutende intellektuelle Herausforderung sowie eine Lösung und kein Problem“, daher sollte sie als eine wichtige Aufgabe für die qualifiziertesten Menschen angesehen werden. Joel Spolsky hat vor langer Zeit geschrieben, dass Entwickler faul sind, und der Grund, warum sie „den Code immer wegwerfen und neu anfangen wollen“, ist, dass „es schwieriger ist, Code zu lesen als ihn zu schreiben“.

In einem Gespräch mit Andy Hunt argumentierte Dave Thomas: „Jede Programmierung ist Wartungsprogrammierung, weil Sie selten Originalcode schreiben. …. Sie verbringen die meiste Zeit im Wartungsmodus. Sie können also genauso gut in den sauren Apfel beißen und sagen: „Ich bleibe vom ersten Tag an.“ Die Disziplinen, die für die Instandhaltung gelten, sollten global gelten.“ Hunt stimmte zu: „Es sind nur die ersten 10 Minuten, in denen der Code original ist, wenn man ihn das erste Mal eintippt. Das ist es."

Atwood tendiert letztendlich zu dieser Sichtweise, gibt aber die allgemeine Sichtweise von WordPress-Entwicklern wieder, die ich von Jason Adams und Timothy Jacobs gehört habe. Die besondere Kunst der WordPress-Entwicklung/Pflege?

„Es ist ein Balanceakt.“

Das beste WordPress-Sicherheits-Plugin zum Sichern und Schützen von WordPress jetzt mit 35 % Rabatt!

WordPress betreibt derzeit über 40 % aller Websites, sodass es zu einem leichten Ziel für Hacker mit böswilligen Absichten geworden ist. Das iThemes Security Pro-Plug-in beseitigt das Rätselraten bei der WordPress-Sicherheit, um es einfach zu machen, Ihre WordPress-Website zu sichern und zu schützen. Es ist, als hätten Sie einen Vollzeit-Sicherheitsexperten im Team, der Ihre WordPress-Site ständig für Sie überwacht und schützt.

Jetzt 35% sparen!