PHP-Version in WordPress aktualisieren – ohne die Seite zu zerschießen

PHP ist der Motor unter deiner WordPress-Seite. Eine veraltete Version ist ein doppeltes Risiko: keine Sicherheitsupdates mehr und weniger Tempo. Laut der PHP-Übersicht der unterstützten Versionen ist PHP 8.1 seit dem 31.12.2025 End-of-Life, PHP 8.2 erhält nur noch bis Ende 2026 Sicherheitsupdates. Wer noch auf 7.x läuft, betreibt die Seite mit Lücken, die niemand mehr schließt. Die Migration ist mit dem richtigen Ablauf gut beherrschbar.

Zuerst: Welche Version läuft überhaupt?

Bevor du etwas änderst, prüfe den Ist-Zustand. Es gibt mehrere Wege, und sie liefern nicht immer dasselbe.

Im Backend. Unter Werkzeuge → Website-Zustand öffnest du den Tab „Bericht” und klappst den Abschnitt „Server” auf. Dort steht die PHP-Version, mit der WordPress im Browser ausgeliefert wird. Zeigt WordPress oben einen Hinweis auf eine veraltete PHP-Version, ist der Handlungsbedarf ohnehin klar.

Im Hosting-Panel. Meist unter „PHP-Einstellungen” oder „PHP-Version”. Hier stellst du später auch um.

Per phpinfo. Eine Datei mit dem Inhalt <?php phpinfo(); im Webroot zeigt Version, geladene Erweiterungen und die verwendete php.ini. Das ist nützlich, wenn Panel und Backend sich widersprechen. Lösche die Datei direkt nach dem Aufruf wieder, denn sie gibt Details über deinen Server preis, die niemand sonst sehen soll.

Per WP-CLI. wp --info zeigt unter anderem „PHP binary”, „PHP version” und die verwendete „php.ini”. Achtung: Das ist die PHP-Version der Kommandozeile, nicht zwingend die des Webservers. Dazu weiter unten mehr.

Welche Version 2026?

Die PHP-Übersicht auf php.net nennt aktuell diese Fristen:

• PHP 8.2: Sicherheitsupdates bis 31.12.2026. Läuft aus, nicht mehr neu wählen.
• PHP 8.3: Sicherheitsupdates bis 31.12.2027.
• PHP 8.4: aktiv unterstützt bis 31.12.2026, Sicherheitsupdates bis 31.12.2028.
• PHP 8.5: Release im November 2025, aktiv unterstützt bis 31.12.2027, Sicherheitsupdates bis 31.12.2029.

Die Systemanforderungen von WordPress empfehlen derzeit PHP 8.3 oder neuer. Das WordPress-Core-Team pflegt außerdem eine Kompatibilitätstabelle, in der aktuelle WordPress-Versionen für PHP 8.0 bis 8.5 als kompatibel geführt werden. Mit dem Core hast du also selten ein Problem.

Unsere Standardwahl ist PHP 8.4: lange Laufzeit, breit getestet. PHP 8.5 ist eine gute Wahl, wenn du Plugins und Theme gut kennst. Hängen viele Fremd-Plugins im Setup, ist 8.4 der entspanntere Weg. PHP 8.3 geht als vorsichtiger Zwischenschritt, aber du verschiebst die nächste Migration nur um ein Jahr.

Zur Geschwindigkeit: Neuere PHP-Versionen sind in der Regel schneller als ältere. Wie viel das bei dir ausmacht, hängt von Plugins, Caching und Hosting ab. Ich nenne hier bewusst keine pauschale Prozentzahl. Der eigentliche Grund für das Update ist ohnehin die Sicherheit: Nur unterstützte Versionen werden gepatcht.

Kompatibilität prüfen, bevor du umstellst

Das meiste Risiko steckt nicht im Core, sondern in Plugins, Themes und eigenem Code. Drei Dinge helfen vorab.

Changelogs lesen. Schau bei jedem Plugin und Theme in den Changelog und die Plugin-Seite. Hinweise wie „PHP 8.4 compatibility” oder „tested up to” sind brauchbar, aber keine Garantie. Ein Plugin, das seit Jahren kein Update bekommen hat, ist der erste Kandidat zum Ersetzen.

Updates vorher einspielen. Aktualisiere Plugins und Theme auf die jeweils aktuelle Version, bevor du PHP umstellst. Kompatibilitätsfixes kommen fast immer über Updates. Wie du das sauber machst, steht in WordPress sicher updaten mit Staging.

Eigenen Code statisch prüfen. Für eigene Themes, Child-Themes und individuelle Plugins gibt es PHPCompatibility, einen Regelsatz für PHP_CodeSniffer. Er prüft Quellcode auf Konstrukte, die in bestimmten PHP-Versionen entfernt oder deprecated wurden. Das Projekt will laut seinem Repository alle Änderungen seit PHP 5.0 bis zur aktuellen Version abdecken und wird aktiv weiterentwickelt. Aufruf nach der Installation per Composer:

vendor/bin/phpcs -ps . --standard=PHPCompatibility --runtime-set testVersion 8.4

Das findet Syntax- und Funktionsprobleme, aber keine Laufzeitfehler, die erst bei bestimmten Daten auftreten. Der Klicktest auf Staging bleibt Pflicht.

So migrierst du sicher

Niemals direkt auf der Live-Seite umschalten. Der Ablauf, den wir nutzen:

1. Backup von Dateien und Datenbank, und zwar eines, das du wiederherstellen kannst.
2. Staging-Kopie anlegen und dort auf die neue PHP-Version stellen.
3. Fehlerlog aktivieren (siehe nächster Abschnitt) und die Seite durchklicken: Startseite, Formulare, Login, Suche, Warenkorb und Checkout, falls vorhanden, außerdem alle Seiten mit Slidern oder Builder-Elementen.
4. Fehler beheben: Inkompatible Plugins aktualisieren oder durch gepflegte Alternativen ersetzen.
5. Cronjobs prüfen (siehe unten).
6. Live umstellen. Wähle einen Zeitpunkt mit wenig Verkehr, an dem du anschließend ein paar Minuten die Seite beobachten kannst.
7. Rollback bereithalten: Die bisherige Version notierst du dir vorher. Tritt ein Problem auf, etwa ein 500-Fehler oder ein weißer Bildschirm, schaltest du im Panel zurück, bis die Ursache geklärt ist.

Fehler sichtbar machen: WP_DEBUG sicher nutzen

Damit du Probleme nicht erst von Besuchern erfährst, aktivierst du auf Staging das Logging. Die WordPress-Entwicklerdoku empfiehlt dafür in der wp-config.php diese Kombination:

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

WP_DEBUG_LOG schreibt standardmäßig nach wp-content/debug.log. WP_DEBUG_DISPLAY auf false verhindert, dass Meldungen im HTML der Seite auftauchen. Dieselbe Doku sagt ausdrücklich, dass die Debug-Werkzeuge nicht für Live-Seiten gedacht sind, sondern für lokale Tests und Staging. Wenn du auf der Live-Seite kurz loggen musst, dann nur für die Dauer der Fehlersuche, mit ausgeschaltetem Display, und lösche die Log-Datei danach. Sie kann Pfade und andere Interna enthalten. Prüfe außerdem, ob debug.log von außen abrufbar ist, und schalte die Konstanten wieder ab.

Typische Fehlerbilder nach dem Wechsel

Wichtig ist der Unterschied zwischen einer Warnung und einem Abbruch.

Deprecated-Meldungen. Sie sagen: Das geht heute noch, bald nicht mehr. Die Seite läuft weiter. Drei Beispiele aus den PHP-Migrationsleitfäden:

• Seit PHP 8.1 ist es deprecated, null an Parameter integrierter Funktionen zu übergeben, die nicht als nullable markiert sind. Der Leitfaden nennt str_contains("foobar", null) als Beispiel. In WordPress-Logs führt das bei älteren Plugins zu viel Rauschen.
• Seit PHP 8.2 ist das dynamische Anlegen von Objekteigenschaften deprecated, sofern die Klasse nicht das Attribut #[\AllowDynamicProperties] nutzt. stdClass ist ausgenommen. Die saubere Lösung ist, die Eigenschaft zu deklarieren.
• Seit PHP 8.4 ist ein Typ mit null als Standardwert, also T $x = null, als implizit nullable deprecated. Die Lösung ist ?T $x = null.

Deprecated-Meldungen sind ein Arbeitsauftrag für den Plugin-Autor oder deine Agentur, aber kein Grund, zurückzurollen.

Fatale Fehler. Hier stoppt PHP. Beispiele aus dem Migrationsleitfaden für PHP 8.0:

• create_function() und each() wurden entfernt. Alter Code, der sie nutzt, endet in einem fatalen Fehler.
• Die Klammer-Schreibweise für Zeichenketten, $string{0}, wurde entfernt. Sie war ein Syntaxfehler.
• count() auf einem Wert, der nicht zählbar ist, etwa null, wirft einen TypeError.
• Arithmetik mit Arrays oder Objekten wirft einen TypeError.

Außerdem änderte PHP 8.0 den Vergleich zwischen Zahl und nicht-numerischem String: 0 == "foo" ist nun false. Das wirft keinen Fehler, kann aber Logik leise verändern. Genau solche Fälle findest du nur im Klicktest.

Kritische Fehler zeigt WordPress seit Version 5.2 mit der Fehlerseite „Es gab einen kritischen Fehler auf deiner Website”. Wie du dann vorgehst, steht in Critical Error beheben.

Recovery-Mode-Mail: Was passiert bei einem Fehler?

Tritt ein fataler Fehler in einem Plugin oder Theme auf, schickt WordPress eine E-Mail an die Admin-Adresse mit einem geheimen Link. Über diesen Link gelangst du in den Wiederherstellungsmodus: Die fehlerhafte Erweiterung wird dort nur für deinen Browser pausiert, für andere Besucher bleibt die Seite im Fehlerzustand. Du kannst dich einloggen und das Plugin deaktivieren oder aktualisieren. Prüfe vorab, dass die Admin-E-Mail-Adresse stimmt und Mails ankommen. Sonst erfährst du vom Fehler nur über Besucher.

CLI-PHP und Web-PHP können abweichen

Das Hosting-Panel stellt oft nur die Version für den Webserver um. Cronjobs, die per Kommandozeile laufen, nutzen unter Umständen ein anderes PHP-Binary mit einer anderen Version. Das betrifft:

• System-Cronjobs, die wp cron event run oder eigene PHP-Skripte aufrufen,
• Deployment- und Wartungsskripte,
• Backup-Skripte, die PHP nutzen.

Prüfe daher im Terminal php -v und wp --info. Steht dort eine andere Version als im Backend, gibst du in Cron-Einträgen den Pfad zum passenden PHP-Binary an. Welche Binaries dein Hoster bereitstellt, steht in dessen Doku.

Die Umstellung beim Hoster

Die meisten Hoster bieten eine Auswahl im Kundenpanel, pro Domain oder pro Webspace. Manche setzen die Version über einen Handler in der .htaccess. Den genauen Eintrag gibt dein Hoster vor, kopiere ihn nur aus dessen Doku, denn ein falscher Handler führt zu einem 500-Fehler. Nach der Umstellung leere Caches (Seiten-Cache, OPcache, falls dein Hoster das anbietet) und rufe Frontend und Backend neu auf.

Rollback-Plan

Ein Rollback ist kein Eingeständnis, sondern Teil des Plans:

1. Vor dem Wechsel die aktuelle Version notieren.
2. Backup prüfen.
3. Bei Fehlern erst die PHP-Version im Panel zurückstellen, dann die Ursache auf Staging analysieren.
4. Das Log lesen, die Ursache beheben, erneut testen.

Kommt es nach der Umstellung zu Datenänderungen, etwa Bestellungen in einem Shop, ist ein Zurückspielen des Backups nicht mehr ohne Weiteres möglich. Dann reicht das Zurückschalten der PHP-Version, nicht das Backup.

Die häufigste Stolperfalle

Probleme entstehen fast nie am WordPress-Core, sondern an alten Plugins und Themes. Je länger eine Installation gewachsen ist, desto höher das Risiko. Typische Symptome nach einem zu forschen Wechsel sind einzeln ausfallende Funktionen (ein Formular, ein Slider) oder der harte Fehler. Deshalb ist der Durchklick auf Staging kein optionaler Schritt.

Das ist auch der Grund, eine PHP-Migration nicht ewig aufzuschieben: Je größer der Versionssprung, desto mehr technische Schulden musst du auf einmal auflösen. Wer regelmäßig in kleinen Schritten aktualisiert, als Teil jeder guten WordPress-Wartung, steht nie vor einem riskanten Riesensprung.

---

Du willst auf PHP 8.4 wechseln, ohne dass etwas kaputtgeht? Schreib uns kurz. Wir migrieren über Staging, prüfen die Kompatibilität und halten den Rollback bereit.