PHP 8.2 ohne Sicherheitsupdates ab 2027: WordPress umstellen

Zum 31. Dezember 2026 endet die Sicherheitsversorgung für PHP 8.2: Danach veröffentlicht das PHP-Projekt für diesen Zweig keine Sicherheitskorrekturen mehr (php.net). Für WordPress ist das keine Randnotiz, denn 24,5 Prozent der an WordPress.org meldenden WordPress-Installationen laufen auf PHP 8.2 (WordPress.org, Stand 27.09.2026). Dieser Leitfaden zeigt, wie Betreiber von WordPress-Websites und WordPress-Shops den Wechsel auf PHP 8.3 oder 8.4 bis zum Jahresende planen, prüfen und umsetzen: von der Bestandsaufnahme über den Test in einer Staging-Umgebung bis zur Umstellung beim Hoster. Wer diese Arbeit nicht selbst übernehmen möchte, findet sie in unserer WordPress-Wartung als festen Bestandteil der laufenden Betreuung.

Was am 31. Dezember 2026 endet

PHP 8.2 erschien am 8. Dezember 2022 (php.net). Die aktive Unterstützung mit regulären Fehlerkorrekturen endete am 31. Dezember 2024; seitdem erhält der Zweig nur noch Sicherheitskorrekturen (php.net). Diese Phase läuft laut php.net bis zum 31. Dezember 2026. Danach erreicht der Zweig sein Lebensende und wird vom PHP-Projekt nicht mehr unterstützt (php.net). Für Betreiber heißt das: Wird nach dem Jahreswechsel eine Sicherheitslücke in PHP bekannt, die auch 8.2 betrifft, gibt es dafür keine Korrektur mehr vom PHP-Projekt.

Dass PHP-Zweige vier Jahre lang versorgt werden, ist eine vergleichsweise junge Regel. Der 2024 angenommene RFC zum Release-Zyklus legt vier Jahre fest: zwei Jahre Fehlerkorrekturen, danach zwei Jahre Sicherheitskorrekturen (PHP-Wiki). Beide Phasen enden laut RFC jeweils am 31. Dezember (PHP-Wiki). Die Änderungen galten sofort für alle damals unterstützten Zweige ab PHP 8.2 (PHP-Wiki); PHP 8.1 erhielt ein zusätzliches Jahr Sicherheitskorrekturen und erreichte sein Lebensende am 31. Dezember 2025 mit Version 8.1.34 (PHP-Wiki, php.net). PHP 7.4 lief noch nach der früheren, kürzeren Regel und ist seit dem 28. November 2022 am Lebensende (php.net). Ähnliche Fristen betreffen auch die Datenbank, wie der Beitrag zum Supportende von MySQL 8.0 zeigt: Laufzeitumgebung und Datenbank gehören in denselben Wartungsplan.

Nach dieser zweijährigen Phase aktiver Unterstützung wird jeder Zweig zwei weitere Jahre nur noch bei kritischen Sicherheitsproblemen versorgt.

The PHP Group, php.net: Supported Versions (eigene Übersetzung)

Bis zum Jahresende versorgt das PHP-Projekt den Zweig 8.2 weiter mit Sicherheitskorrekturen, sofern sie nötig werden. Beim Abruf am 27. September 2026 war die jüngste Veröffentlichung PHP 8.2.34 vom 24. September 2026, gekennzeichnet als Sicherheitsrelease; die vorherige, PHP 8.2.33, erschien am 30. Juli 2026 (php.net). Wer 8.2 heute betreibt, sollte also nicht nur den Wechsel planen, sondern bis dahin auch die laufenden Korrekturen einspielen. Ob einzelne Hoster oder Linux-Distributionen 8.2 nach dem Jahreswechsel mit eigenen Korrekturen weiterversorgen, lässt sich nicht allgemein sagen. Das kann nur der jeweilige Anbieter beantworten, und eine solche Zusage sollte schriftlich vorliegen, bevor man sich darauf verlässt.

Wie verbreitet PHP 8.2 bei WordPress ist

WordPress.org veröffentlicht, auf welchen PHP-Versionen die an WordPress.org meldenden WordPress-Installationen laufen. Beim Abruf am 27.09.2026 entfielen 24,535 Prozent auf PHP 8.2, gerundet 24,5 Prozent (WordPress.org). Am stärksten vertreten war PHP 8.3 mit 25,748 Prozent, gerundet 25,7 Prozent (WordPress.org, Stand 27.09.2026). PHP 8.2 folgt damit direkt hinter 8.3 und ist im WordPress-Bestand kein Randfall. Die folgenden Summen sind eigene Additionen über die einzelnen Felder der Statistik.

Legt man diese Zahlen neben den Kalender, ergibt sich ein deutliches Bild: Bliebe es bei dieser Verteilung, stünde ab dem 1. Januar 2027 die Mehrheit der an WordPress.org meldenden WordPress-Installationen auf Zweigen, für die das PHP-Projekt keine Sicherheitskorrekturen mehr veröffentlicht. Zusammengerechnet 62 Prozent auf PHP 8.2 oder älter stehen 37,8 Prozent auf 8.3 oder neuer gegenüber (WordPress.org, Stand 27.09.2026; php.net). Wie stark sich die Verteilung bis dahin verschiebt, ist offen. Der Abstand zeigt aber, wie viele Installationen den Wechsel noch vor sich haben.

Eine zweite Zählung stammt von W3Techs. Deren Stichprobe umfasst nach eigener Angabe weit über 20 Millionen Websites (W3Techs). Innerhalb der Websites mit PHP 8 laufen dort 29,4 Prozent auf PHP 8.2 und 33,2 Prozent auf PHP 8.3; 8.3 ist damit der größte Unterzweig von PHP 8 (W3Techs, Stand 1. September 2026). Unter allen Websites mit PHP laufen laut W3Techs noch 28,7 Prozent auf der Hauptversion 7 (W3Techs, Stand 1. September 2026); deren letzter Zweig 7.4 erhält seit dem 28. November 2022 keine Sicherheitskorrekturen mehr (php.net).

Was WordPress empfiehlt und was es noch zulässt

WordPress.org empfiehlt für den Betrieb von WordPress PHP 8.3 oder neuer (WordPress.org). Gleichzeitig läuft WordPress laut WordPress.org in Altumgebungen, in denen nur ältere Versionen verfügbar sind, auch mit PHP 7.4 oder neuer und MySQL 5.5.5 oder neuer (WordPress.org). Das ist eine Aussage über Lauffähigkeit, keine Empfehlung: WordPress.org weist im selben Hinweis darauf hin, dass diese älteren Versionen ihr offizielles Lebensende erreicht haben und die Website Sicherheitslücken aussetzen können. Laut php.net trifft das für PHP 7.4 bis 8.1 zu (php.net); PHP 8.2 erreicht diesen Punkt erst nach dem 31. Dezember 2026.

Für WordPress 7.0 und 7.1 nennt die Kompatibilitätstabelle jeweils PHP 7.4 bis 8.5 als kompatibel, PHP 7.3 und älter nicht mehr (WordPress.org). Mit WordPress 7.0 wurde die Unterstützung für PHP 7.2 und 7.3 eingestellt (WordPress.org). Diese Kompatibilität bezieht sich auf den WordPress-Kern, nicht auf Themes und Plugins. PHP 8.3 gilt seit Juli 2025 für WordPress 6.8 als voll kompatibel (WordPress.org). Wer also noch eine ältere WordPress-Version betreibt, sollte zuerst WordPress selbst aktualisieren und erst danach die PHP-Version wechseln.

Seine PHP-Hinweise bezieht WordPress aus der Serve-Happy-Schnittstelle von WordPress.org. Für PHP 8.2 meldet sie is_supported: false, also nicht mehr aktiv unterstützt, empfiehlt Version 8.3 und nennt 7.4 als Mindestversion (WordPress.org). Die Angabe „nicht mehr aktiv unterstützt“ beschreibt den heutigen Stand; das Ende der Sicherheitskorrekturen folgt zum Jahresende. Im Quelltext der Funktion wp_check_php_version() ist zudem festgehalten, dass die minimal unterstützte PHP-Version künftig auf mindestens 8.0 angehoben wird; einen Termin nennt der Quelltext nicht (WordPress.org). Welche Schutzmaßnahmen neben der PHP-Version zählen, fasst unser Beitrag zur WordPress-Sicherheit 2026 zusammen.

Zielversion wählen: 8.3, 8.4 oder 8.5

Gegenüber PHP 8.2 bringt PHP 8.3 ein Jahr mehr Sicherheitsversorgung, PHP 8.4 zwei Jahre und PHP 8.5 drei Jahre (php.net). Mehr Laufzeit bedeutet weniger Wechsel in den kommenden Jahren. Eine neuere Version setzt aber voraus, dass Theme und Plugins sie bereits vertragen, und je jünger die Version, desto öfter fehlt diese Freigabe noch. Die Empfehlung von WordPress.org, PHP 8.3 oder neuer, erfüllen alle drei Kandidaten (WordPress.org).

• Herstellerangaben prüfen: Für Plugins und Themes steht in der Regel auf der Produktseite oder im Änderungsprotokoll, bis zu welcher PHP-Version getestet wurde. Fehlt die Angabe, ist das ein Prüfauftrag, kein Ausschlussgrund.
• Shop-Erweiterung zuerst: Bei einem WordPress-Shop entscheiden die Shop-Erweiterung und ihre Zahlungs- und Versandmodule über die Zielversion. Für Shops wählen wir in der Regel 8.3 oder 8.4; PHP 8.5 kommt erst infrage, wenn alle Hersteller der eingesetzten Erweiterungen sie als getestet ausweisen.
• Angebot des Hosters: Nicht jeder Tarif stellt jede Version bereit. Welche Versionen verfügbar sind und bis wann, gehört in dieselbe Abfrage.
• Eigener Code: Individuelle Plugins, Theme-Anpassungen und Snippets in der functions.php werden wie fremde Plugins geprüft. Für sie gibt es keinen Hersteller, der vorab testet.
• Wartungsrhythmus: Wer ohnehin regelmäßig wartet, kommt mit 8.3 in der Regel gut zurecht; der nächste Wechsel steht dann Ende 2027 an (php.net).

Schritt 1: Bestandsaufnahme

Am Anfang steht eine nüchterne Liste: Welche PHP-Version läuft, welche WordPress-Version, welches Theme, welche Plugins in welcher Version, und welche davon sind aktiv? Mit WP-CLI lässt sich das auf der Kommandozeile in wenigen Befehlen erheben. Wer keinen Shellzugang hat, findet die Angaben im WordPress-Backend unter Werkzeuge und Website-Zustand.

• PHP-Version der Live-Umgebung und der Staging-Umgebung
• WordPress-Version und Stand der automatischen Aktualisierungen
• Aktives Theme, Eltern-Theme und eigene Anpassungen
• Alle Plugins mit Version, Status und Datum der letzten Aktualisierung
• Selbst entwickelte Plugins und Snippets ohne externen Hersteller
• Zahlungs-, Versand- und Schnittstellenmodule eines Shops
• Cronjobs und Hintergrundprozesse, die PHP außerhalb von WordPress aufrufen
• Zuständigkeiten: Wer entscheidet beim Hoster, wer testet, wer gibt frei?

Besondere Aufmerksamkeit verdienen Plugins, die seit längerer Zeit keine Aktualisierung mehr erhalten haben. Sie sind erfahrungsgemäß eine häufige Quelle für Überraschungen beim PHP-Wechsel. Für jedes davon gibt es drei Wege: aktualisieren, ersetzen oder, wenn es nicht mehr gebraucht wird, entfernen. Die Entscheidung fällt leichter, wenn in der Liste auch steht, wofür das Plugin genutzt wird und wer es im Unternehmen braucht.

Schritt 2: Kompatibilität prüfen

Die Prüfung hat zwei Ebenen. Die erste ist schnell und grob: Lässt sich der gesamte PHP-Code überhaupt mit der Zielversion einlesen? Ein Syntax-Check mit dem PHP-Interpreter der Zielversion findet Parse-Fehler, also Code, der mit der neuen Version gar nicht mehr startet. Veraltete Funktionsaufrufe und Laufzeitfehler findet er nicht.

# Alle PHP-Dateien in wp-content mit PHP 8.4 einlesen
# (findet nur Parse-Fehler, keine Laufzeitprobleme)
find wp-content -name '*.php' -print0 \
  | xargs -0 -n1 php8.4 -l \
  | grep -v 'No syntax errors'

Die zweite Ebene ist aufwendiger und aussagekräftiger: Die Website läuft in einer Testumgebung mit der Zielversion, und alle Hinweise von PHP werden in eine Logdatei geschrieben. Dafür reichen drei Einträge in der wp-config.php der Testumgebung. Auf der Live-Website bleibt die Anzeige von Fehlern abgeschaltet, weil Fehlermeldungen Pfade und Details preisgeben können.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Nach einem Durchgang durch die wichtigsten Seiten und Abläufe steht in wp-content/debug.log, welche Plugins veraltete Funktionen nutzen oder Warnungen erzeugen. Die Einträge lassen sich meist einem Plugin- oder Theme-Verzeichnis zuordnen, weil der Dateipfad in der Meldung steht. Drei Arten von Einträgen sind zu unterscheiden:

• Deprecated: Eine Funktion oder Schreibweise gilt als veraltet. Heute noch lauffähig, in einer späteren PHP-Version möglicherweise nicht mehr. Kein Hindernis für die Umstellung, aber ein Eintrag für die nächste Wartung.
• Warning: Etwas läuft anders als erwartet, die Seite wird aber ausgeliefert. Oft ein Hinweis auf fehlerhafte Datenverarbeitung, der vor der Umstellung geklärt werden sollte.
• Fatal error: Die Ausführung bricht ab. Betroffene Seiten oder Funktionen sind nicht nutzbar. Das ist ein Grund, die Umstellung zu verschieben, bis die Ursache behoben ist.

Wenn ein Plugin nicht mitkommt

• Aktualisierung abwarten: Hat der Hersteller eine angepasste Version angekündigt und ist das Plugin nicht geschäftskritisch, lässt sich der Wechsel darauf abstimmen. Dazu gehört ein Termin, zu dem spätestens entschieden wird.
• Ersetzen: Für viele Aufgaben gibt es gepflegte Alternativen. Ein Tausch braucht einen eigenen Test, weil Daten und Einstellungen übernommen werden müssen.
• Anpassen: Bei eigenem Code oder aufgegebenen Plugins mit überschaubarem Umfang ist eine Anpassung an die Zielversion oft der kürzere Weg.
• Entfernen: Plugins, deren Funktion im Unternehmen keine Rolle mehr spielt, verschwinden sinnvollerweise ganz. Jedes entfernte Plugin ist eine Prüfung weniger, auch bei künftigen Wechseln.

Schritt 3: Test in der Staging-Umgebung

Die Testumgebung ist eine Kopie der Live-Website mit identischem Code und möglichst aktuellen Daten, aber mit eigener Adresse und der Zielversion von PHP. Voraussetzung ist eine frische, geprüfte Sicherung, nicht nur für die Kopie, sondern auch als Rückweg für den Live-Wechsel. Wie Sicherung und Wiederherstellung belastbar aufgebaut werden, beschreibt unser Beitrag zu Backup und Disaster Recovery für Online-Shops.

1. Sicherung von Dateien und Datenbank der Live-Website erstellen und die Wiederherstellung probeweise durchführen.
2. Staging-Kopie anlegen, für Suchmaschinen per noindex sperren und den Zugang mit einem Passwort schützen.
3. PHP-Version der Staging-Umgebung auf die Zielversion umstellen und das Debug-Log aktivieren.
4. Theme und Plugins auf den Stand bringen, den ihre Hersteller für die Zielversion freigegeben haben.
5. Kernabläufe durchklicken: Startseite, Suche, Formulare, Anmeldung, Warenkorb, Kasse, Kundenkonto.
6. Hintergrundaufgaben prüfen: Cronjobs, Importe, Exporte, Newsletter- und Schnittstellenabgleiche.
7. Debug-Log auswerten, jeden Befund einem Plugin oder Codeteil zuordnen und beheben oder ersetzen.
8. Ergebnis dokumentieren: Was wurde getestet, was war auffällig, was wurde geändert, wer hat freigegeben?

Besonderheiten bei WordPress-Shops

Ein Shop auf WordPress-Basis hat beim PHP-Wechsel mehr bewegliche Teile als eine Unternehmenswebsite: die Shop-Erweiterung selbst, Zahlungsanbieter, Versandmodule, Rechnungs- und Buchhaltungsanbindungen, oft auch eine Warenwirtschaft. Jedes dieser Module wird von einem anderen Hersteller gepflegt und hat einen eigenen Veröffentlichungsrhythmus. Ein Fehler im Rechnungsmodul fällt beim Durchklicken der Startseite nicht auf, wohl aber beim ersten echten Kauf nach der Umstellung. Deshalb gehören in den Test zusätzlich:

• Zahlungsmodule: die Kasse im Testmodus vollständig durchlaufen, einschließlich Abbruch und Erstattung.
• Versand: Etikettenerstellung und Sendungsverfolgung mit Testdaten prüfen.
• Rechnungen: Erzeugung, Nummernkreis und Versand der Rechnungsdokumente kontrollieren.
• Schnittstellen: den Abgleich mit Warenwirtschaft, Marktplätzen oder Buchhaltung in beide Richtungen testen.
• Zeitgesteuerte Aufgaben: Bestandsabgleich, Preisimporte und Produktfeeds laufen oft nachts; ihre Protokolle nach dem ersten Lauf lesen.

Schritt 4: Umstellung beim Hoster oder auf dem eigenen Server

Bei vielen Hosting-Tarifen ist die PHP-Version eine Einstellung je Website oder je Verzeichnis. Der Wechsel selbst ist dann schnell erledigt; die Arbeit liegt davor und danach. Wichtig ist, dass die Umstellung zu einer ruhigen Zeit passiert, dass jemand die Website direkt danach prüft und dass der Rückweg auf 8.2 bis zum Jahresende offensteht, falls doch etwas übersehen wurde. Bei unserem Hosting mit Server-Wartung stimmen wir den Zeitpunkt der Umstellung vorher mit Ihnen ab. Auf einem eigenen Server laufen mehrere PHP-Versionen in der Regel parallel, jeweils mit eigenem FPM-Pool. Die Website wird dann nicht umgebaut, sondern ihr Eintrag im Webserver zeigt auf den Pool der neuen Version. Der alte Pool bleibt bis zum Jahresende installiert, aber ungenutzt. So ist der Rückweg ein einzelner Konfigurationswechsel.

• PHP-Version im Website-Zustand von WordPress kontrollieren
• Startseite, Kasse, Formulare und Anmeldung aufrufen
• PHP-Fehlerlog des Servers in den ersten Stunden beobachten
• Cronjobs und geplante Aufgaben am nächsten Tag kontrollieren
• Rückweg dokumentieren: Welche Einstellung stellt 8.2 wieder her, und wer darf sie auslösen?

Zeitplan bis zum Jahresende

Zwischen Anfang Oktober und dem 31. Dezember liegen knapp drei Monate, und im Handel sind es nicht die ruhigsten. Wer einen Shop betreibt, wird zwischen Mitte November und Weihnachten ungern die Laufzeitumgebung tauschen. Wie sich Lastspitzen in dieser Zeit abfedern lassen, beschreibt unser Beitrag zum virtuellen Warteraum für Black Friday. Für den PHP-Wechsel heißt das: Die Umstellung sollte vor der heißen Phase erledigt sein.

1. Oktober, Bestandsaufnahme und Zielversion: Versionen erfassen, veraltete Plugins markieren, Zielversion festlegen, Angebot des Hosters klären.
2. Oktober bis Anfang November, Staging-Test: Testumgebung aufsetzen, Debug-Log auswerten, Plugins aktualisieren oder ersetzen, Befunde beheben.
3. Anfang bis Mitte November, Umstellung live: Wartungsfenster außerhalb der Stoßzeiten, Umstellung, Kontrolle direkt danach und am Folgetag.
4. Mitte November bis Ende Dezember, Beobachtung: Fehlerlog und Abläufe im Blick behalten, keine größeren Änderungen im Weihnachtsgeschäft, Rückweg auf 8.2 bis zum Jahreswechsel verfügbar halten.
5. Ab Januar 2027, Aufräumen: PHP 8.2 aus Tarif oder Server entfernen, Dokumentation abschließen, nächsten Wechsel vormerken. PHP 8.3 erhält Sicherheitskorrekturen bis Ende 2027, PHP 8.4 bis Ende 2028 (php.net).

Der Plan passt nicht nur zu WordPress. Wer neben einer WordPress-Website einen Shop auf anderer Basis betreibt, kann Wartungsfenster bündeln und Tests gemeinsam planen. Wie ein solches Upgrade für einen Shopware-Shop vorbereitet wird, zeigt unser Beitrag zum Upgrade auf Shopware 6.8.

So unterstützen wir bei der Umstellung

Den PHP-Wechsel begleiten wir im Rahmen unserer WordPress-Wartung: Aktualisierungen von Kern, Theme und Plugins testen wir in einer Staging-Umgebung, spielen Sicherheits-Patches ein, sichern täglich und überwachen die Erreichbarkeit. Tritt nach einer Aktualisierung ein Konflikt auf, spielen wir den vorherigen Stand zurück.

Welche Variante passt, hängt davon ab, wie viel Sie selbst betreuen möchten und wie Ihre Website heute gehostet ist. In einem kurzen Gespräch klären wir den Stand und den Zeitplan bis zum Jahresende; schreiben Sie uns dazu über das Kontaktformular für eine Ersteinschätzung.