WordPress-PHP-Version aktualisieren: Was Sie vor dem Umstieg prüfen sollten

Bevor Sie die PHP-Version Ihrer WordPress-Seite aktualisieren, brauchen Sie zwei Antworten: auf welche Version Sie umstellen und was Sie vorher prüfen. PHP (Hypertext Preprocessor) ist die Sprache, auf der WordPress läuft.

Ziel ist eine aktuelle Version, Stand Oktober 2026 also PHP 8.4 oder 8.5. Die Live-Seite stellen Sie erst um, wenn eine Kopie den Test bestanden hat: Plugins und Theme geprüft, die Wiederherstellung der Sicherung ausprobiert und kein fataler Fehler (Fatal Error) mehr im Protokoll.

Warum sollten Sie die PHP-Version Ihrer WordPress-Seite jetzt aktualisieren?

Jeder PHP-Zweig bekommt zwei Jahre aktive Unterstützung und danach zwei weitere Jahre nur noch Korrekturen für kritische Sicherheitslücken, so steht es bei php.net, der Seite des PHP-Projekts. Für PHP 8.2 endet diese zweite Phase am 31. Dezember 2026 (Stand Oktober 2026). Danach schließt niemand mehr neu entdeckte Lücken in dieser Version.

PHP 8.1 bekommt schon seit dem 31. Dezember 2025 keine Sicherheitsupdates mehr. Angreifer nutzen bekannte Lücken in Plugins, Themes und veralteter Server-Software aus, und PHP gehört zu dieser Server-Software: Wer Updates liegen lässt, lässt diese Lücken offen. Die PHP-Version gehört deshalb zur laufenden Pflege, wie ich sie in der WordPress-Wartung übernehme; der Ratgeber zur WordPress-Sicherheit ordnet, welche Schutzmaßnahmen sonst zuerst kommen. Bleibt die Frage, auf welche Version.

Auf welche PHP-Version sollten Sie umstellen?

PHP 8.4 bekommt laut php.net bis zum 31. Dezember 2028 Sicherheitsupdates, PHP 8.5 bis Ende 2029, und der WordPress-Kern ist ab 6.7 mit PHP 8.4 und ab 6.9 mit PHP 8.5 getestet (Stand Oktober 2026). Wer umstellt, sollte deshalb gleich auf 8.4 oder 8.5 gehen. PHP 8.3 nehme ich nur als Zwischenschritt, wenn ein Plugin 8.4 noch nicht verträgt.

WordPress selbst setzt die Grenze niedriger: Auf seiner Seite zu den Server-Anforderungen empfiehlt das Projekt „PHP version 8.3 or greater“, also PHP 8.3 oder höher (Stand Oktober 2026). Die Empfehlung und mein Rat widersprechen sich nicht, denn 8.4 und 8.5 liegen darüber. Der Unterschied ist die Laufzeit: Wer jetzt auf 8.3 umstellt, steht Ende 2027 wieder vor demselben Schritt.

Läuft Ihre Seite schon auf PHP 8.3, bekommt sie laut php.net noch bis zum 31. Dezember 2027 Sicherheitsupdates und erfüllt die WordPress-Empfehlung. Beim nächsten Umstieg gehen auch Sie gleich auf die aktuelle Version. Bietet Ihr Hoster weder PHP 8.4 noch 8.5 an, beschreibt der Ratgeber Website umziehen und Hoster wechseln, wie ein Wechsel abläuft.

WordPress hat die Einschränkung „beta support“ für neue PHP-Versionen im Mai 2026 abgeschafft; die Kompatibilitätsübersicht im Core-Handbuch führt 8.4 und 8.5 als getestet. Dieselbe Übersicht erinnert aber daran, dass WordPress selten ohne Theme und Plugins läuft, und dort liegt das eigentliche Risiko.

Wie prüfen Sie vorher, ob Plugins und Theme die neue Version vertragen?

Sehen Sie zuerst nach, welche PHP-Version Ihre Seite heute nutzt: im WordPress-Backend unter Werkzeuge, Website-Zustand (Site Health), Tab Bericht, Abschnitt Server. Prüfen Sie dann Plugins und Theme: ob der Hersteller sie noch pflegt, ob eigener Code darin steckt und ob sie Schreibweisen nutzen, die PHP 8.4 als veraltet meldet. Die PHP-Angabe im Plugin-Verzeichnis nennt nur eine Mindestversion.

In 28 von 107 Plugin-Ordnern aus Kopien von drei WordPress-Installationen, an denen ich 2026 gearbeitet habe, steckt mindestens eine Stelle, die PHP 8.4 als veraltet meldet; in jeder der drei Installationen waren es mindestens sechs Plugins. Ich habe statisch nur eine Änderung aus PHP 8.4 gezählt: die implizit nullbaren Parametertypen wie function foo(T1 $a = null), die laut PHP-Handbuch ab 8.4 ?T1 $a = null heißen sollen. Die Zahl sagt nicht, ob die Plugins aktiv waren. Ein solcher Deprecated-Hinweis ist kein Absturz: Solange die Fehleranzeige ausgeschaltet ist, landet er nur im Fehlerprotokoll.

In denselben 107 Ordnern nennen 70 Plugins eine Mindestversion „Requires PHP“, 67 davon liegen unter PHP 8.0, und die höchste Angabe war 8.2. Das passt zum Zweck des Feldes: Laut Plugin-Handbuch von WordPress nennt es die mindestens nötige Version, ein Feld für eine höchste Version gibt es nicht. Gelesen habe ich die Dateien der Kopien; im Plugin-Verzeichnis kann bei einer neueren Fassung ein anderer Wert stehen.

Die PHP-Angabe beruhigt vor dem Umstieg auf 8.4 also nicht. Ob ein Plugin die neue Version verträgt, zeigt erst der Test in einer Kopie. Auch das PHP-Compatibility-Checker-Plugin, das die Supportseite des WordPress-Projekts zum PHP-Update nennt, ist laut dieser Seite „nicht perfekt“ und kann Elemente übersehen.

Auch abgeschaltete Plugins gehören in die Prüfung. In einer der drei Installationen, deren Plugin-Ordner ich 2026 durchsucht habe, lagen noch mehrere Plugins, die create_function() aufrufen, eine Funktion, die es seit PHP 8.0 nicht mehr gibt; ob sie aktiv waren, habe ich nicht geprüft. Schaltet jemand so ein Plugin ein und ruft es die Funktion auf, bricht PHP mit einem fatalen Fehler ab. Drei Installationen zeigen, dass es vorkommt, nicht, wie häufig. Ein Klick ändert, ob ein Plugin aktiv ist; prüfen Sie deshalb den ganzen Plugin-Ordner:

Wie stellen Sie die PHP-Version Schritt für Schritt um?

Stellen Sie zuerst eine Kopie um und erst danach die Live-Seite. Vorher legen Sie eine Sicherung an, deren Wiederherstellung Sie ausprobiert haben, und bringen WordPress, Plugins und Theme auf den neuesten Stand. In der Kopie lassen Sie Fehler ins Protokoll schreiben und testen Formular, Login und Bestellvorgang. Die Live-Seite bleibt so unberührt, bis die Kopie ohne fatalen Fehler läuft.

1. Sicherung anlegen und Wiederherstellung ausprobieren

   Legen Sie direkt vor der Umstellung ein frisches Backup von Dateien und Datenbank außerhalb des Webspace an und probieren Sie aus, ob es sich zurückspielen lässt. Eine Sicherung, die nie zurückgespielt wurde, ist ungeprüft. Die Anleitung zum WordPress-Backup zeigt, wie eine Sicherung nach der 3-2-1-Regel aussieht.

2. WordPress, Plugins und Theme aktualisieren

   Spielen Sie die vorhandenen Updates vor dem Wechsel ein, damit WordPress mindestens die Version hat, die laut Core-Handbuch mit Ihrer PHP-Zielversion getestet ist: 6.7 für PHP 8.4, 6.9 für PHP 8.5 (Stand Oktober 2026). Eine neuere Fassung eines Plugins kann außerdem Stellen bereinigt haben, die eine ältere noch enthält.

3. Testkopie auf die neue PHP-Version umstellen

   Legen Sie eine Kopie der Seite an, eine sogenannte Staging-Umgebung, und stellen Sie nur für diese Kopie die neue PHP-Version ein. Wie das geht, hängt vom Hoster ab: Lässt Ihr Hosting-Kundenmenü die PHP-Version je Domain oder Subdomain einstellen, legen Sie die Kopie unter einer eigenen Subdomain an. Gilt eine Version für alle Domains Ihres Pakets, bitten Sie den Hoster um eine getrennte Testumgebung.

4. Fehler ins Protokoll schreiben statt anzeigen

   Öffnen Sie in der Kopie die Datei wp-config.php, suchen Sie die Zeile define( 'WP_DEBUG', false ); und ersetzen Sie sie durch diese vier Zeilen; fehlt die Zeile, setzen Sie die vier Zeilen oberhalb der Zeile mit That's all, stop editing! ein:

   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_LOG', true );
   define( 'WP_DEBUG_DISPLAY', false );
   @ini_set( 'display_errors', 0 );
   

   WordPress schreibt Fehler, Hinweise und Warnungen dann in die Datei debug.log im Ordner wp-content und zeigt sie nicht an. Für die Umstellung gehören die Zeilen nur in die Kopie, und dazu passt die WordPress-Dokumentation zum Debugging, die Debug-Werkzeuge für lokale Tests und Staging-Installationen vorsieht. Nach der Prüfung setzen Sie WP_DEBUG wieder auf false und nehmen die drei übrigen Zeilen heraus. Der Beitrag zum Debug-Modus: loggen statt anzeigen erklärt, was jeder Schalter bewirkt.

5. Formular, Login und Bestellvorgang testen

   Gehen Sie in der Kopie durch, was Ihre Besucher nutzen: das Kontaktformular, die Anmeldung und, wenn Ihre Seite einen Shop hat, den Bestellvorgang bis zur Bestätigung. Lesen Sie danach die debug.log. Steht dort ein Fatal Error, ist die Kopie noch nicht so weit.

6. Live-Seite umstellen

   Erst wenn die Kopie ohne Fatal Error läuft, stellen Sie auch die Live-Seite um, im Hosting-Kundenmenü oder über Ihren Hoster. Notieren Sie vorher, welche PHP-Version bisher eingestellt war: Das ist Ihr erster Weg zurück.

Was tun Sie, wenn nach der Umstellung Fehler auftauchen?

Unterscheiden Sie zuerst die Fehlerart. Ein Fatal Error bricht die Ausführung ab; WordPress zeigt dann eine Fehlermeldung und schickt seit Version 5.2 eine Mail mit einem Link in den Wiederherstellungsmodus an die Administrator-Adresse. Warnungen und Deprecated-Hinweise halten die Seite nicht an. Bei einem Fatal Error stellen Sie die vorige PHP-Version zurück und suchen die Ursache in der Kopie.

Diese Unterscheidung stammt aus dem PHP-Handbuch; es beschreibt einen Deprecated-Hinweis als Warnung vor Code, der in künftigen Versionen nicht mehr funktionieren wird.

Für die 28 Plugin-Ordner aus der Zählung oben heißt das: Wer eine Testkopie auf 8.4 umstellt, muss mit Deprecated-Hinweisen im Protokoll rechnen, sofern PHP die betroffenen Dateien lädt. Ob die Umstellung live gehen kann, hängt deshalb an den Fatal Errors; Deprecated-Hinweise allein sind kein Grund, die Umstellung aufzuschieben. Melden Sie sie trotzdem dem Hersteller des Plugins, damit der Code auch die nächste Version übersteht.

Steht ein Fatal Error im Protokoll oder zeigt die Live-Seite einen kritischen Fehler, suchen Sie die Ursache nicht auf der Live-Seite. In der WordPress-Wartung gilt bei mir für missglückte Updates diese Reihenfolge:

„Macht ein Update etwas kaputt, setze ich Ihre Website auf das Backup zurück, das ich direkt vor dem Update angelegt habe. Danach suche ich die Ursache und spiele das Update erst wieder ein, wenn es zuverlässig läuft.“

— Sascha Fix

Bei der PHP-Umstellung heißt Zurücksetzen zuerst: die vorige PHP-Version wieder einstellen. Die Sicherung brauchen Sie erst, wenn das Zurückstellen nicht reicht, und dann zusammen mit der vorigen Version; so beschreibt es auch die Supportseite des WordPress-Projekts. Das Zurückstellen verschafft Ihnen Zeit für die Suche in der Kopie. Es ist ein Übergang, denn auch die vorige Version bekommt keine oder nur noch befristet Sicherheitsupdates.

Der Beitrag WordPress-Error-Logs finden und verstehen zeigt, wie Sie eine Fehlerzeile im Protokoll dem auslösenden Plugin zuordnen; bleibt nur eine weiße Seite, hilft der Ratgeber WordPress weiße Seite beheben. Verträgt ein Plugin, auf das Sie nicht verzichten können, die neue Version dauerhaft nicht, rät die Supportseite des WordPress-Projekts, den Entwickler zu fragen und ohne Antwort ein Plugin mit ähnlicher Funktion zu suchen. Bis dahin ist PHP 8.3 der Zwischenschritt, keine Dauerlösung.

Wann lohnt es sich, die PHP-Umstellung abzugeben?

Die PHP-Version Ihrer WordPress-Seite können Sie selbst aktualisieren, wenn Sie eine Testkopie anlegen können, Plugins und Theme vom Hersteller gepflegt werden und Sie eine Sicherung haben, deren Wiederherstellung Sie ausprobiert haben. Fehlt eine dieser Bedingungen, fehlt Ihnen der Test oder der Weg zurück, und bei eigenem Code oder einem Shop steht mehr auf dem Spiel.

In der WordPress-Wartung behalte ich die PHP-Version Ihrer Seite im Blick, prüfe vor der Umstellung, ob Ihre Plugins mit der neuen Version laufen, und stelle mit Test um. Hat die Umstellung die Seite schon beschädigt, übernehme ich die Website-Reparatur zu einem Festpreis, den Sie vor dem Start kennen.