PHP 8.2 endet am 31.12.2026: WordPress sicher auf PHP 8.4 umstellen, ohne kritischen Fehler

Die Support-Tabelle auf php.net nennt diese Termine:

PHP 8.6 soll am 19. November 2026 erscheinen.

Am 1. Jänner läuft Ihre Seite weiter, nur kommt vom PHP-Projekt kein Fix mehr. Am 21. Oktober 2026 hat es vor zwei kritischen Lücken gewarnt, über die Angreifer ohne Anmeldung eigenen Code auf dem Server ausführen können, und mit 8.2.35 auch für 8.2 noch ein Update veröffentlicht. Ab Jänner hängt so ein Fix an Ihrem Hoster. Drei Beispiele, Stand November 2026:

• World4You nennt in seiner Anleitung zum Versionswechsel den PHP Extended Support "kostenpflichtig" und den Wechsel auf eine aktuelle Version "kostenlos".
• easyname benachrichtigt Kund:innen mit veralteter PHP-Version laut seiner Seite zum Extended Support per E-Mail, "bevor der kostenpflichtige PHP Extended Support aktiviert wird". Ab wann 8.2 dort als veraltet gilt, steht nicht dabei.
• Host Europe aus Deutschland stellt auf seiner Classic-Hosting-Plattform am 9. November 2026 alle Domains mit 8.2 auf 8.4 um. Zurück auf 8.2 geht es dort nur bis 7. Dezember. Dann deaktiviert Host Europe 8.2 und stellt alle verbliebenen Domains "unwiderruflich auf PHP 8.4" um.

Extended Support verschafft Zeit. Der Hoster liefert weiter Sicherheitsupdates, Sie zahlen dafür, und Ihre Plugins werden nicht kompatibler. Manche Updates verlangen schon mehr als 8.2. Contact Form 7 setzt in Version 6.2.4.1 PHP 8.3 voraus, und auf 8.2 meldet WordPress nur "Es ist eine neue Version von Contact Form 7 verfügbar, die jedoch mit deiner PHP-Version nicht kompatibel ist.", im Sprachpaket Deutsch (Österreich) "Es gibt eine neue Version von Contact Form 7, aber sie funktioniert nicht mit deiner PHP-Version."

Betroffen ist vor allem Shared Hosting, wo jemand die PHP-Version vor Jahren eingestellt hat und seither keiner hinsieht. WordPress selbst ist nicht das Problem. Laut der Kompatibilitätstabelle im Core-Handbuch läuft es ab 6.4 mit PHP 8.3, ab 6.7 mit 8.4 und ab 6.9 mit 8.5. Ärger machen:

• Themes, deren Update-Lizenz abgelaufen ist.
• Plugins, die ihr Entwickler aufgegeben hat.
• Eigener Code im Child-Theme oder in einem Plugin, das eine frühere Agentur eigens für Sie geschrieben hat.
• Plugins, die Mails per IMAP abholen. PHP 8.4 hat IMAP, OCI8, PDO_OCI und PSpell aus dem Standardpaket nach PECL verschoben. Ob Ihr Hoster IMAP nachinstalliert, erfahren Sie nur dort.
• Plugins, die ohne function_exists-Prüfung eine eigene array_find() definieren. PHP 8.4 bringt array_find(), array_find_key(), array_any() und array_all() selbst mit, und die zweite Definition endet mit "Cannot redeclare function".

Wo Ihre Seite steht, zeigt Werkzeuge > Website-Zustand. Auf 8.2 meldet WordPress dort "Deine Website wird mit einer älteren PHP-Version (8.2.x) ausgeführt, die aktualisiert werden sollte", im Sprachpaket Deutsch (Österreich) "Auf deiner Website läuft eine ältere Version von PHP (8.2.x), die aktualisiert werden sollte". Die genaue Version steht unter Werkzeuge > Website-Zustand > Bericht > Server.

Wir empfehlen 8.4. Backup, Kopie und Tests kosten dieselbe Arbeit wie für 8.3, aber 8.4 bekommt ein Jahr länger Sicherheitsupdates. WordPress läuft zwar seit 6.9 auch mit 8.5, wegen der Plugins halten wir aber 8.4 derzeit für die sicherere Wahl. Für PHP 8.6 nennt das Core-Handbuch noch keine Unterstützung.

Finden Sie im Panel keine PHP-Einstellung oder kein 8.4? Bitten Sie den Support Ihres Hosters, die Seite umzustellen oder eine Testkopie auf 8.4 laufen zu lassen. Bietet er nur kostenpflichtigen Extended Support an, ist ein Umzug oft der sauberere Weg.

1. Ein Backup, das Sie zurückspielen können

Sichern Sie Datenbank, wp-content und wp-config.php, auch wenn Ihr Hoster selbst Backups macht. Legen Sie den Datenbank-Dump außerhalb des Web-Verzeichnisses ab, sonst kann ihn jeder herunterladen:

mkdir -p ~/backups
wp db export ~/backups/vor-php-84.sql

Ohne SSH-Zugang exportieren Sie die Datenbank in phpMyAdmin und laden die Dateien per SFTP herunter.

2. Eine Staging-Kopie mit eigener Datenbank

Testen Sie nie zuerst live. Kopieren Sie die Website in einen neuen Ordner und lassen Sie eine Subdomain darauf zeigen, für die Sie die PHP-Version getrennt einstellen können. Das geht nicht bei jedem Hoster. Bei World4You etwa gilt die PHP-Version für den ganzen Webspace (Dein Paket > Webspace > Einstellungen). Fragen Sie dann nach einem vorübergehenden zweiten Paket für die Kopie, oder lassen Sie uns die Kopie aufsetzen. Die kopierte wp-config.php verweist aber noch auf die Live-Datenbank. Jede Änderung an der Kopie träfe dann Ihre echte Website.

Legen Sie deshalb eine neue, leere Datenbank an und tragen Sie deren Zugangsdaten in die wp-config.php der Kopie ein (DB_NAME, DB_USER, DB_PASSWORD, manchmal auch DB_HOST). Dann geht es im Ordner der Kopie weiter:

cd ~/staging
wp config get DB_NAME   # muss die neue Datenbank zeigen
wp db import ~/backups/vor-php-84.sql
wp search-replace 'https://www.example.at' 'https://staging.example.at' --skip-columns=guid

Ohne SSH erledigt ein Migrations-Plugin Import und Adresstausch. Die leere Datenbank brauchen Sie trotzdem.

Damit die Kopie keine Mails an Kund:innen schickt und keine geplanten Aufgaben ausführt, setzen Sie in ihrer wp-config.php define( 'DISABLE_WP_CRON', true ); und legen die Datei wp-content/mu-plugins/keine-mails.php an, samt Ordner, falls er fehlt:

<?php
add_filter( 'pre_wp_mail', '__return_true' );
add_filter( 'action_scheduler_allow_async_request_runner', '__return_false' );

WordPress verschickt dann nichts, Formulare melden aber Erfolg. Bei WooCommerce startet der Action Scheduler seine Warteschlange zusätzlich bei jedem Aufruf im Backend, auch mit DISABLE_WP_CRON. Der zweite Filter verhindert das. Newsletter-Plugins mit eigenem Versanddienst pausieren Sie in deren Einstellungen. Zuletzt kommt ein Passwortschutz auf die Kopie, damit Google sie nicht indexiert und niemand darüber bestellt.

3. Aktualisieren, dann die Kopie auf 8.4 stellen

Bringen Sie auf der Kopie zuerst alles auf den neuesten Stand, was sich unter 8.2 installieren lässt: WordPress, Themes und Plugins. Eine alte Plugin-Version kann unter 8.4 abstürzen, auch wenn die aktuelle läuft. Dann stellen Sie die Subdomain auf PHP 8.4 und holen die Updates nach, die mindestens 8.3 verlangen, etwa Contact Form 7. Notieren Sie die Reihenfolge. Live gehen Sie später genauso vor.

Im Plugin-Verzeichnis bezieht sich "Getestet bis" auf WordPress, und "PHP-Version" ist nur eine Untergrenze.

4. Den Code mit PHPCompatibilityWP prüfen

Dieser Schritt ist für die Person, die Ihren Code betreut: Sie führt ihn auf einem Rechner mit PHP und Composer aus, neben einer heruntergeladenen Kopie der Seite. Ohne beides geht es mit Schritt 5 weiter.

PHPCompatibilityWP ist ein Regelwerk für PHP_CodeSniffer, das Plugin- und Theme-Code gegen eine PHP-Version prüft und weiß, welche neueren PHP-Funktionen WordPress selbst nachrüstet.

Die letzte stabile Version der Prüfregeln, PHPCompatibility 9.3.5, stammt vom Dezember 2019 und kennt PHP 8.4 nicht. Die Regeln für PHP 8 gibt es bisher nur als Alpha der Version 10, also muss Composer Alphas erlauben:

mkdir php-check && cd php-check
echo '{}' > composer.json
composer config allow-plugins.dealerdirect/phpcodesniffer-composer-installer true
composer config minimum-stability alpha
composer config prefer-stable true
composer require --dev phpcompatibility/phpcompatibility-wp:"^3.0@alpha"

vendor/bin/phpcs -p ../meine-seite/wp-content/plugins ../meine-seite/wp-content/themes \
  --standard=PHPCompatibilityWP --extensions=php --runtime-set testVersion 8.4

Ein ERROR führt unter 8.4 zum Absturz, sobald die Stelle ausgeführt wird, etwa "Function imap_open() is removed since PHP 8.4". Ein WARNING betrifft meist Code, den PHP als veraltet markiert, der unter 8.4 aber noch läuft.

Das Werkzeug findet nicht alles. In unserem Test mit einem Demo-Plugin hat es eine selbst definierte array_find() übersehen. php -l unter PHP 8.4 findet sie sofort. Prüfen Sie vorher mit php -v, dass auf dem Rechner PHP 8.4 läuft:

find ../meine-seite/wp-content -name '*.php' -exec php -l {} \; 2>&1 | grep "Fatal error"

Mit ionCube verschlüsselte Plugins kann keines der beiden Werkzeuge lesen. Da hilft nur die Nachfrage beim Hersteller.

5. Die Kopie testen

Klicken Sie sich durch wie ein Kunde: Startseite, Kontaktformular, Checkout bis zur Zahlungsseite, Login, Backend, ein Bild hochladen. Dann lesen Sie das Debug-Log, eingeschaltet wie weiter unten beschrieben. Wichtig sind Zeilen mit "PHP Fatal error". Meldungen wie "Implicitly marking parameter $post as nullable is deprecated" brechen unter 8.4 nichts.

grep "PHP Fatal error" ~/logs/wp-debug.log | tail -20

6. Live nachziehen und umstellen

Machen Sie direkt davor ein frisches Backup wie in Schritt 1. Dann wiederholen Sie live, was auf der Kopie funktioniert hat, in derselben Reihenfolge: die Updates unter 8.2, den Wechsel auf 8.4, die restlichen Updates. Die Kopie einfach über die Live-Seite zu spielen, kostet bei Shops alle Bestellungen seit dem Kopieren.

Notieren Sie vor dem Wechsel die alte PHP-Version, damit Sie sofort zurückkönnen. Bei World4You liegt die Einstellung unter my.world4you.com > Dein Paket > Webspace > Einstellungen. Wählen Sie 8.4 und klicken Sie auf "PHP-Version wechseln". Bei Host Europe finden Sie sie im KIS unter Produktverwaltung > Ihr Produktbereich > Konfigurieren > Skripte & Datenbanken > PHP-Versionen.

7. Live testen

Gehen Sie die Runde aus Schritt 5 auf der Live-Seite noch einmal durch und lesen Sie danach das Log. Live gehen Mails wirklich hinaus. Schicken Sie also eine Formularanfrage an Ihre eigene Adresse und prüfen Sie, ob sie ankommt.

Seit Version 5.2 fängt WordPress fatale PHP-Fehler ab. Im Backend und auf der Login-Seite steht dann "Es gab einen kritischen Fehler auf dieser Website", dazu der Hinweis auf eine E-Mail an die Admin-Adresse. Besucher:innen sehen eine kürzere Meldung: "Auf dieser Website ist ein kritischer Fehler aufgetreten", im Sprachpaket Deutsch (Österreich) "Es gab einen kritischen Fehler auf deiner Website". Der Server antwortet dazu mit Status 500.

Kommt der Fehler direkt nach dem Wechsel, stellen Sie zuerst die alte PHP-Version wieder ein. World4You beschreibt das in seiner Anleitung als Schritt 5. Ihre Seite läuft dann wieder, und Sie suchen die Ursache auf der Kopie statt unter Zeitdruck. Ohne Rückweg helfen die drei Wege unten.

Der Link in der E-Mail

WordPress schickt eine Mail mit dem Betreff "[Name Ihrer Website] Ihre Website hat ein technisches Problem", in Du-Sprachpaketen "Deine Website hat ein technisches Problem". Sie nennt das Plugin oder Theme, das den Fehler ausgelöst hat, und enthält einen Link in den Wiederherstellungsmodus. Dort pausiert WordPress das fehlerhafte Plugin, aber nur für Ihre Sitzung. Besucher:innen sehen den Fehler weiter, bis Sie das Plugin deaktivieren oder ersetzen.

• Der Link gilt standardmäßig einen Tag, und WordPress schickt höchstens eine solche Mail pro Tag.
• Die Mail geht an die Administrator-Adresse aus den Einstellungen. Ist das noch das Postfach einer früheren Agentur, setzen Sie in der wp-config.php eine andere: define( 'RECOVERY_MODE_EMAIL', 'technik@example.at' );
• Liegt der Fehler nicht in einem Plugin oder Theme, gibt es keinen Wiederherstellungsmodus.
• Verschickt Ihr Server keine Mails, kommt auch diese nicht an.

Das Debug-Log einschalten

Fehlt die Mail, lesen Sie das Log. Fügen Sie in der wp-config.php vor der Zeile "That's all, stop editing!" ein (im deutschen Sprachpaket steht darüber "Das war’s, Schluss mit dem Bearbeiten!"):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/ihr-benutzer/logs/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Steht dort schon define( 'WP_DEBUG', false );, ersetzen Sie diese Zeile. Der Ordner logs muss existieren und für PHP beschreibbar sein, sonst entsteht kein Log. Er liegt mit Absicht außerhalb des Web-Verzeichnisses. Mit true statt eines Pfads schreibt WordPress nach wp-content/debug.log, und diese Datei kann ohne eigene Sperre jeder abrufen. Die WordPress-Dokumentation rät vom Debug-Modus auf Live-Seiten ab. Schalten Sie ihn aus, sobald Sie die Ursache kennen.

Plugin abschalten per SFTP oder WP-CLI

Ohne Backend benennen Sie per SFTP den Ordner des Plugins um, etwa wp-content/plugins/kontaktformular-pro in kontaktformular-pro.aus. WordPress lädt das Plugin dann nicht mehr. Mit SSH-Zugang geht es schneller:

# Welche PHP-Version nutzt WP-CLI? Auf Shared Hosting oft eine andere als die Website.
wp cli info

# Aktive Plugins sichern, bevor Sie etwas abschalten
wp plugin list --status=active --field=name --skip-plugins --skip-themes > aktive-plugins.txt

# Ein Plugin abschalten, ohne Plugins und Theme zu laden
wp plugin deactivate kontaktformular-pro --skip-plugins --skip-themes

# Notfall: alle Plugins aus
wp plugin deactivate --all --skip-plugins --skip-themes

# Liegt es am Theme: auf ein Standard-Theme wechseln
wp theme activate twentytwentyfive --skip-plugins --skip-themes

# Ist das Standard-Theme gelöscht: neu installieren und aktivieren
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

Danach aktivieren Sie die Plugins aus aktive-plugins.txt einzeln mit wp plugin activate und rufen nach jedem die Seite auf.

Mit SFTP-Zugang und einem ruhigen Nachmittag schaffen Sie das meiste selbst. Holen Sie sich Hilfe, wenn das abstürzende Plugin geschäftskritisch ist und kein Update mehr bekommt, wenn Ihr Shop rund um die Uhr verkauft und es keine Staging-Kopie gibt, wenn der Rückweg zur alten PHP-Version schon zu ist, oder wenn Ihr Hoster kein 8.4 anbietet oder nur kostenpflichtigen Extended Support.

Als WordPress-Agentur in Linz reparieren wir solche Plugins, statt Ihnen zu sagen, Sie sollen ein anderes kaufen. Was wir bei Abstürzen, Fehlern und alten Plugins übernehmen, steht unter Bugfixing, Wartung und Optimierung. Liegt es am Hoster, übersiedeln wir die Seite auf unser Hosting, testen sie auf dem neuen Server und stellen um, sobald alles läuft.

Ein kurzes Gespräch kostet nichts. Schreiben Sie uns über das Kontaktformular, auf welcher PHP-Version Ihre Seite läuft und welche Plugins Ihnen Sorgen machen. Wir antworten meist innerhalb eines Werktags.