Eine WordPress-Website, ein Plugin oder ein Theme auf eine neue PHP-Version zu aktualisieren, ist eine Aufgabe, die regelmäßig wiederkehrt. Aber wie kannst du das so effizient wie möglich machen? Woher weißt du, dass du nichts übersehen wirst? Gibt es einen Fahrplan dafür?

In diesem Artikel gehen wir auf diese Fragen (und mehr) ein und schauen uns an, was für eine reibungslose Umstellung auf PHP 8.x für deine WordPress-Website, dein Plugin oder dein Theme nötig ist, einschließlich einer Roadmap.

Dabei stützen wir uns auf ein Interview, das wir mit der PHP-Expertin Juliette Reinders Folmer geführt haben. Sie widmet einen Großteil ihres Alltags der Programmierung und allem, was damit zusammenhängt, und konzentriert sich dabei vor allem auf Open-Source-Projekte, darunter WordPress.

Bist du auch bereit, den Umstieg reibungslos zu schaffen? Bist du neugierig auf unseren Schritt-für-Schritt-Plan? Dann lass uns gleich loslegen!

PHP 8.x – Was sich geändert hat

Um einen Überblick über die Änderungen zu bekommen, empfehlen wir die folgenden Artikel:

Nachdem du diese Artikel gelesen hast, bist du auf dem neuesten Stand, was sich in PHP 8.x geändert hat und was du tun musst, damit deine PHP-Projekte problemlos laufen.

Wenn du dir unsicher bist, wie du am besten anfängst, ist das kein Problem. Im Gespräch mit Juliette haben wir das ausführlich besprochen, und wir erklären dir in diesem Artikel so ausführlich wie möglich, wie du auf PHP 8.x umsteigen kannst.

Außerdem erklären wir dir in informativen Kästen, wie du verschiedene Vorgänge in MyKinsta, unserem firmeneigenen Kontrollpanel für alle deine WordPress-Sites, Anwendungen und Datenbanken, durchführen kannst.

Der Umstieg auf PHP 8.x: So fängst du an

Die Umstellung auf PHP 8.x klingt einfach und ist es auch. Bei vielen Hostern kannst du im Admin-Panel angeben, welche PHP-Version du für deine Website verwenden möchtest. Bei Kinsta kannst du die PHP-Version mit einem einzigen Klick im MyKinsta-Dashboard umstellen.

Aber bevor du das tust, musst du dir über einige Dinge im Klaren sein. Je nach deinem Wissensstand und deiner Erfahrung empfehlen wir Folgendes:

  • Wenn du deine eigene WordPress-Seite mit Standard-Themes und -Plugins erstellt hast, ohne viel über PHP zu wissen, solltest du einen Entwickler oder eine Agentur damit beauftragen, zu prüfen, ob deine Seite für PHP 8.x geeignet ist Dann sieh dir unsere Partnerseite an, auf der einige vertrauenswürdige Unternehmen aufgelistet sind, die dir helfen können.
  • Wenn deine WordPress-Website von einem externen Unternehmen, einem Entwickler oder einer Agentur erstellt wurde, solltest du dich bei ihnen erkundigen, ob deine Website mit PHP 8.x betrieben werden kann.
  • Wenn du deine WordPress-Website selbst erstellt hast, z. B. mit einem eigenen Theme oder selbst entwickelten Plugins, haben wir unten eine Roadmap für dich.

Wenn deine Website in eine der ersten beiden Kategorien fällt, solltest du dir den Rest des Artikels durchlesen, aber wir empfehlen dir nicht, deine Website selbst auf PHP 8-Kompatibilität zu testen. Überlass das lieber den Profis.

Wie auch immer du dich entscheidest, wir würden dir raten, nicht einfach deine Live-Site auf PHP 8 umzustellen und „zu sehen, ob es funktioniert“ Bist du neugierig darauf, wie deine Website aussehen wird, und kannst es kaum erwarten, sie unter PHP 8 laufen zu sehen? Dann beginne mit den Tests in einer Staging-Umgebung. Bei einem guten Hoster kannst du ganz einfach eine Staging-Umgebung einrichten.

MyKinsta - Eine neue Umgebung erstellen
MyKinsta – Eine neue Umgebung erstellen

In der Staging-Umgebung kannst du PHP 8.x aktivieren und sehen, ob das Update gut mit deiner Website funktioniert. Es ist auch möglich, mit einer lokalen Kopie deiner Website zu arbeiten. Mit unserem kostenlosen Entwicklungstool DevKinsta kannst du deine Website ganz einfach aus dem MyKinsta-Dashboard importieren und anschließend die PHP-Version auf 8.0 oder 8.1 ändern.

Wenn du in der Staging-Umgebung keine Probleme siehst, heißt das nicht unbedingt, dass es keine Probleme gibt. In der Roadmap unten erfährst du, warum.

PHP 8.x Kompatibilitätstests: Der Wegweiser

Testen: das Schlüsselwort für gute Software. Auch bei WordPress-Websites und ihren Komponenten, wie Themes, Plugins und dem WordPress-Kern, ist Testen das Mittel, um sicherzustellen, dass nichts passiert, was du nicht willst.

Ein Softwareentwicklungsprojekt besteht zu einem großen Teil aus Testen. In diesem Artikel gehen wir speziell auf die Tests ein, die dir helfen können, den Übergang zu PHP 8.x reibungslos zu gestalten. In unserem Artikel über DevOps-Tools findest du einen Abschnitt mit einer Sammlung von Tools, die du verwenden kannst.

Die folgenden Arten von Tests werden in diesem Blogbeitrag besprochen:

Schauen wir uns die verschiedenen Arten von Tests, die wir durchführen können, genauer an.

Statische Analyse (oder statische Tests)

Der erste Schritt, den du als PHP-Entwickler/in machen kannst, ist eine statische Analyse deines Codes mit verschiedenen Tools. Bei der statischen Analyse wird die Software analysiert, ohne dass der Code ausgeführt wird. Mit der statischen Analyse ist es möglich, Fehler aufzuspüren, Probleme mit der Kompatibilität von PHP 8.x zu erkennen, Codierungsstandards durchzusetzen (z. B. die WordPress Coding Standards) und sogar den Code zu ändern und zu bereinigen.

Tools für die statische Analyse

Du kannst eine statische Analyse mit verschiedenen Tools durchführen, wie z. B.:

Zum Zeitpunkt der Erstellung dieses Artikels werden nicht alle PHP 8.1 Checks in der neuesten PHPCompatibility Version unterstützt. PHP 8.1-Prüfungen können in der Entwicklungsversion enthalten sein. Stelle also sicher, dass du diese (vorerst) verwendest, wenn du dein Projekt mit PHPCompatibility analysierst und siehst, welche Fehler/Empfehlungen auftauchen.

Die PHP 8.1 Checks werden bald in einer neuen Hauptversion veröffentlicht. Wenn du darüber auf dem Laufenden bleiben willst und ein GitHub-Konto hast, öffne das GitHub-Repository von PHPCompatibility und navigiere zu Beobachten -> Benutzerdefiniert -> Releases, wo du auswählen kannst, ob du benachrichtigt werden willst, wenn eine neue Version veröffentlicht wird.

PHPCompatibility, das nur die Kompatibilität für eine bestimmte Version (oder eine Reihe von Versionen) von PHP testet, ist einfach einzurichten. Die besten Ergebnisse erhältst du, wenn du innerhalb von PHPCompatibility eine testVersion – zum Beispiel 8.0+ (8.0 und höher) – ausführst.

Du solltest auf veraltete oder gelöschte Funktionen achten, auf geänderte Standardwerte von Funktionsparametern, auf die Verwendung von concat ohne Klammern, auf die Verwendung von match als Funktionsname (da es seit PHP 8.0 reserviert ist), usw.

Screenshot von der PHPCompatibility GitHub-Seite
Screenshot von der PHPCompatibility GitHub-Seite

Psalm und PHPStan sind gute Ergänzungen und können dir helfen, indem sie zusätzliche Prüfungen in Bezug auf Variablentypen durchführen. Der Nachteil dieser Tools ist, dass es eine Menge Konfiguration braucht, um Berichte über PHP 8.0 und 8.1 zu erhalten. Selbst wenn sie erfolgreich sind, musst du mit vielen falsch positiven Meldungen rechnen. False Positives sind Meldungen, die aufgrund der Einschränkungen der statischen Analyse fälschlicherweise ausgegeben werden.

Um die Ergebnisse dieser beiden Tools richtig zu interpretieren, sind fundierte Kenntnisse erforderlich, aber diese Kenntnisse können dir helfen, zusätzliche Inkompatibilitäten zu erkennen, die PHPCompatibility nicht finden kann. Schau dir die Dokumentation von Psalm und PHPStan an, wenn du mehr darüber erfahren willst.

Zusammenfassung:

  • Statische Analyse mit PHPCompatibility, Psalm und PHPStan durchführen
  • Behebe alle legitimen Probleme
MyKinsta - Logdateien ansehen
MyKinsta – Logdateien ansehen

Unit-Tests

Der nächste Schritt im Prozess ist das Unit Testing. Beim Unit-Testing werden die einzelnen Teile des Codes getestet. Bei den Unit-Tests werden für jede Unit spezielle, gezielte Tests entwickelt. Dabei werden verschiedene Szenarien durchgespielt. Vorzugsweise wird jedes Szenario getrennt von den anderen getestet, damit die Tests unabhängig voneinander sind.

Unit-Tests allein einzurichten reicht natürlich nicht aus. Sie müssen auch ausgeführt werden. Unit-Tests lassen sich am besten mit CI-Werkzeugen (Continuous Integration) wie Jenkins, GitHub Actions oder Travis automatisieren.

Ein Beispiel von GitHub Actions
Ein Beispiel von GitHub Actions

Unterstützung für mehrere PHP-Versionen

Wenn du als Plugin-Entwickler mehrere PHP-Versionen unterstützen willst, musst du sicherstellen, dass die Tests in CI für alle von dir unterstützten PHP-Versionen ausgeführt werden.

Natürlich kannst du auch nur neuere Versionen unterstützen – die Entscheidung liegt ganz bei dir.

Das Testen mit mehreren PHP-Versionen erfordert, dass du je nach PHP-Version mehrere PHPUnit-Versionen verwendest. Da PHPUnit im Laufe der Jahre mehrere Änderungen eingeführt hat, die sich auf die Art und Weise auswirken, wie Tests geschrieben werden, kann dieser Teil knifflig sein.

Um dies zu umgehen, kannst du die PHPUnit Polyfills verwenden (geschrieben von Juliette und gesponsert von Yoast). Damit kannst du Tests schreiben, die offiziell nicht von PHPUnit 9 unterstützt werden (und daher auf PHP 8.x laufen können). Die Polyfills sorgen dann dafür, dass deine Tests in PHPUnit 4.x bis 9.x und mit PHP 5.4 bis PHP 8.1 (ab sofort) funktionieren.[/notice]

Jetzt, wo die Tests laufen, musst du im nächsten Schritt sicherstellen, dass die in den Tests gefundenen Probleme behoben werden.

Code-Abdeckung

Die Durchführung dieser Tests ist der zuverlässigste Weg, um versionsübergreifende Inkompatibilitäten zu finden.

Achte dabei auf die Codeabdeckung deiner Tests:

  • Angenommen, du hast eine Funktion A, für die du einen Test geschrieben hast, und die Funktion A ruft die Funktionen B, C und D als Teil der Logik der Funktion auf.
  • Der Test für die Funktion A wurde geschrieben, um die Logik der Funktion A zu testen, aber er wird auch die Funktionen B, C und D während des Tests aufrufen. Für die Funktionen B, C und D testest du dann in der Regel nur den „glücklichen Weg“ – die Situation, in der alles gut läuft – und somit sind auch diese Funktionen noch nicht vollständig getestet, obwohl (ein Teil) des Codes in diesen Funktionen während der Prüfung von Funktion A ausgeführt wird.
  • Gib für jeden deiner Tests an, welcher Code gerade getestet wird. Das tust du, indem du jedem Test ein @covers gibst. Auf diese Weise werden B, C und D bei der Berechnung der Codeabdeckung nicht „mitgezählt“ und du kannst sehen, welcher Teil deines Codes von den Tests abgedeckt wird.

Oft schreiben und testen Entwickler – manchmal sogar unbewusst – für den „glücklichen Weg“ In diesen Fällen muss auch getestet werden, was passiert, wenn unerwartete Daten an eine Funktion übergeben werden. Es reicht nicht aus, nur mit erwarteten Werten/Typen zu testen.

Der zweite Teil des obigen Zitats wird oft vergessen, obwohl er vielleicht noch wichtiger ist als der erste Teil. Was passiert, wenn du einen falschen Typ übergibst? Bekommst du eine Fehlermeldung? Oder wird die Variable ganz normal mit der Funktion weitergegeben? Was ist, wenn ein unerwarteter Wert an die Funktion übergeben wird?

Teste deine Funktionen unbedingt mit unerwarteten Variablen, Typen und Werten. Nur dann kannst du dich auf deine Tests verlassen, um Probleme zu finden, die eine neue PHP-Version verursachen könnte.

PHP wird immer strikter

PHP wird immer präziser (strikter), was die Behandlung von „Typen“ für PHP-eigene Funktionen und Dinge wie dynamische Eigenschaften angeht. Diese Änderungen sollen Entwicklern helfen, fehlerfreien Code (oder zumindest Code mit weniger Fehlern) zu erstellen. Dies kann jedoch eine ziemliche Hürde für bereits bestehenden Code darstellen, der auf der Grundlage der „alten“ Grundsätze von PHP geschrieben wurde.

Aufgrund dieses Strebens nach hilfreicheren Fehlermeldungen in PHP wird die Anpassung von bestehendem Code an neue PHP-Versionen immer zeitaufwändiger. Die Anpassung von Code, der mit PHP 5.6 funktionierte, an PHP 7.0 nahm in den meisten Fällen nur einen Bruchteil der Zeit in Anspruch, verglichen mit der Anpassung von Code von PHP 7.0 an PHP 8.1. Und das, obwohl PHP 7.0 eine „Major“-Version war, während PHP 8.1 eine „Minor“-Version ist

In vielen Fällen ist das Testen immer noch die einzige zuverlässige Methode, um festzustellen, was geändert werden muss, um eine neue Version zu unterstützen.

Unit-Tests sind mit verschiedenen Tools möglich, z. B:

Viele dieser Tools basieren auf oder in Verbindung mit PHPUnit.

Letztlich ist es egal, welche Tools du verwendest. Das Wichtigste ist, dass du testest und die Tests auf neuen PHP-Versionen zum Laufen bringst. Dieser Schritt kann manchmal sehr knifflig sein, aber zum Glück gibt es dafür, wie bereits erwähnt, Tools wie die PHPUnit Polyfills.

Integrationstests

Integrationstests sind der nächste Schritt, den wir nach der statischen Analyse und den Unit-Tests durchführen werden. Bei einem Integrationstest werden reale Situationen in einem größeren Kontext als nur einer „Codeeinheit“ getestet Dazu gehören Tests mit einer aktiven (Test-)Datenbank oder Tests mit einer externen API, um nur zwei Beispiele zu nennen.

Wenn du also den Code eines Plugins oder Themes im Kontext von WordPress testest und eine reale Version verwendest, handelt es sich per Definition um Integrationstests.

WP Test Utils (ebenfalls von Juliette geschrieben und von Yoast gesponsert) ist ein hervorragendes Tool für Integrationstests. WP Test Utils bietet Werkzeuge zum Schreiben von Integrations- und Unit-Tests, bei denen WordPress mithilfe von Brainmonkey und Mockery „nachgebildet“ wird, wobei häufig verwendete WordPress-Funktionen „vorgetäuscht“ werden, damit du deinen eigenen Code und nicht den WordPress-Code testest.

WP Test Utilities auf GitHub
WP Test Utilities auf GitHub

Integrationstests mit WordPress sind eine kompliziertere Angelegenheit, weil sie die Integration mit WordPress und der WordPress-Testsuite erfordern. Je nachdem, welche WordPress-Versionen ein Plugin oder Theme unterstützt, musst du berücksichtigen, welche PHPUnit-Versionen von WordPress selbst unterstützt werden, um die Tests mit verschiedenen PHP-Versionen durchzuführen.

WordPress 5.6 bis 5.8 verwendet zum Beispiel PHPUnit 5 bis 7, um PHP 5.6 bis PHP 8.0 zu testen, aber seit WordPress 5.9 verwendet WordPress selbst auch PHPUnit Polyfills für eine breitere Unterstützung. WP Test Utils dient als Brücke, um all diese Unterschiede zu überwinden.

Willst du mehr darüber erfahren, wie du Integrationstests mit mehreren verschiedenen WordPress-Versionen, einschließlich WordPress 5.9 und höher, durchführen kannst? Dann lies auf der WordPress-Website darüber mehr.

Manuelle Tests

Nachdem du die Unit-Tests und Integrationstests durchgeführt und alle gefundenen Probleme behoben hast, ist es an der Zeit, manuelle Tests durchzuführen. Deine Website läuft und dein eigener Code funktioniert, aber du verwendest auch Plugins A, B und C. Weißt du, ob diese Plugins kompatibel sind?

Frag zum Beispiel bei den Autoren des Plugins nach, ob sie angeben, dass es mit PHP 8.x kompatibel ist. Die Frage ist dann natürlich, wie das Plugin getestet wurde. Oft lautet die Antwort: in Isolation. Die Funktionen des Plugins wurden in der Regel nur in Verbindung mit WordPress getestet, ohne andere aktive Plugins. Und selbst wenn andere Plugins in diesen Tests verwendet wurden, ist die Wahrscheinlichkeit groß, dass nicht alle von dir verwendeten Plugins Teil der Tests waren.

Ein Beispiel: Eine WordPress-Website mit 3 Plugins (A, B und C). Es ist möglich, dass Plugin B zum Beispiel über einen Filter einen falschen Variablentyp zurückgibt, mit dem Plugin C, das denselben Filter verwendet, arbeiten möchte. Das kann dann zu einem fatalen Fehler führen, weil der Typ nicht mehr dem erwarteten entspricht. Plugin C wird dann als Schuldiger für die Fehlermeldung angesehen, obwohl Plugin B der eigentliche Übeltäter ist.

Plugin-Interoperabilität – Unverträglichkeiten sind unmöglich zu entdecken, wenn man isoliert testet. Je mehr Plugins aktiv sind, desto wahrscheinlicher ist es, dass etwas schief geht. Es wäre zum Beispiel sehr nützlich, Seitenanfragen von einer Live-Website an eine Staging-Umgebung (mit aktivierter Fehlerprotokollierung) weiterzuleiten, um herauszufinden, was tatsächlich schief läuft.

Bei dieser Art von Problem sieht der Website-Betreiber in der Regel nur eine Meldung, dass ein Fehler beim zuletzt ausgeführten Code (in diesem Fall von Plugin C) aufgetreten ist, obwohl Plugin C nicht unbedingt die Ursache des Problems ist.

In den meisten Fällen ist viel manuelle Arbeit und eine gehörige Portion Muskelkraft erforderlich, um diese Probleme zu erkennen und zu beheben. Dies könnte mit Hilfe von End-to-End-Tests automatisiert werden, aber wir sehen nicht, dass dies in WordPress häufig geschieht.

Testverfügbarkeit für genutzte Plugins

Für Entwickler und Entwicklungsteams: Akzeptiere Code nur, wenn Tests verfügbar sind. Auf diese Weise stellst du sicher, dass weniger manuelle Tests erforderlich sind, was dir viel Zeit spart.

Hinterfrage die Teststrategie, wenn du ein kommerzielles Plugin oder Theme kaufen willst. Auf diese Weise schaffen wir gemeinsam ein Bewusstsein unter den Entwicklern/Entwicklungsteams in der WordPress-Gemeinschaft, damit das Testen einen höheren Stellenwert erhält, und wir alle profitieren davon.

Testen wird oft – zu Unrecht – als Kostenfaktor angesehen, obwohl es in Wirklichkeit Geld spart. Die zusätzliche Investition, die für das Schreiben von Tests erforderlich ist, zahlt sich in Form von deutlich weniger Fehlermeldungen und weniger Zeitaufwand für die Behebung von Fehlern aus. Außerdem können mit automatisierten Softwaretests Erweiterungen und Änderungen schneller durchgeführt werden, weil die Tests schnell bestätigen können, dass die bestehenden Funktionen weiterhin funktionieren.

Die Rolle von WordPress-Hosts und PHP 8.x

Für den durchschnittlichen Website-Betreiber ist eine Anleitung von deinem Hoster sehr wünschenswert. Denke an Folgendes:

  • Dokumentation und Updates für Kunden, die wissen, dass WordPress Core, Plugins und/oder Themes (in manchen Fällen) nicht PHP-kompatibel sind
  • Möglichkeiten zum Testen (z. B. mit einer Staging-Umgebung arbeiten)
  • Methoden zur Fehlermeldung und Kontaktaufnahme mit dem Support

Dies kommt auch dem Webhoster zugute, da sich Websitebetreiber/innen bei Problemen oft an ihn wenden. Bei einer Umstellung auf PHP 8.0, 8.1, oder 8.2 ist der Website-Betreiber für mögliche Probleme verantwortlich, und je mehr Informationen er hat, um sich richtig auf die Umstellung vorzubereiten, desto besser.

PHP 8.1 oder 8.2 den Kunden als Webhoster zur Verfügung zu stellen, ist eine Sache, aber dabei muss sichergestellt werden, dass die Kunden darauf aufmerksam gemacht werden, dass Probleme auftreten können. Es wird empfohlen, deine Website in einer Staging-Umgebung mit einer anderen Version als der Live-Version zu testen. (Die Auswahl der PHP-Versionen ist bei Kinsta standardmäßig verfügbar.)

Mindest-PHP-Version für WordPress

Über 15 % aller Websites verwenden derzeit die PHP-Version 7.0 oder niedriger. Das geht aus den offiziellen WordPress-Statistiken hervor. Etwa 83% aller WordPress-Websites verwenden derzeit die PHP-Version 7.4 oder niedriger. Bitte beachte, dass alles, was kleiner oder gleich der Version 8.0 ist, derzeit nicht mehr von PHP unterstützt wird. Die Verwendung von End-of-Life-Versionen von PHP kann zu Problemen führen, weil keine Sicherheitsupdates mehr veröffentlicht werden.

Um Probleme zu vermeiden, ist es wichtig, dass die Betreiber von WordPress-Websites über die Mindest-PHP-Version informiert sind, mit der ihre Website sicher betrieben werden kann. Website-Betreiber/innen können ihrerseits die PHP-Version selbst ändern (bei Kinsta für alle Pakete möglich) oder ihren Hoster bitten, die Website auf eine neuere PHP-Version zu aktualisieren. In extremen Fällen kannst du zu einem Hoster wechseln, der diese neueren Versionen unterstützt.

Da WordPress nur eine Mindestversion von 7.4 benötigt, gibt es für viele Hoster und Website-Betreiber keine ausreichende Motivation, ihre Websites zu aktualisieren. Und das, obwohl PHP 7.4 im November 2022 das Ende seiner Lebensdauer erreicht hat.

Sollte WordPress die Mindest-PHP-Version jemals erhöhen, könnte dies bedeuten, dass viele Websites nicht mehr mit einem Update auf die neueste WordPress-Version kompatibel sind. Allerdings werden für diese veralteten Versionen noch eine ganze Weile Sicherheitsupdates veröffentlicht.

Zusammenfassung

Um für deine Website auf PHP 8.0 oder höher umzusteigen, musst du oder dein/e Entwickler/in mehrere Schritte durchführen. Wichtige Schritte sind:

  • Statische Analyse
  • Unit-Tests
  • Integrationstests
  • Manuelles Testen

Wenn du auf PHP 8.x umsteigst, musst du sicherstellen, dass alles richtig getestet wurde. Nur so kannst du garantieren, dass deine Website auch mit einer neueren PHP-Version ordnungsgemäß, schnell und sicher läuft.

Wir danken Juliette herzlich für die Mitarbeit an diesem Artikel und für ihre Arbeit an den erwähnten Tools!

Das Foto von Juliette wurde von Jip Moors aufgenommen und mit Genehmigung verwendet.

Marcel Bootsman Kinsta

Business Development Manager Dutch and DACH Markets