PHP 8.2 erhält nur noch bis zum 31. Dezember 2026 Sicherheitskorrekturen durch das PHP-Projekt. Wer seine Unternehmenswebsite damit betreibt, sollte den Wechsel jetzt vorbereiten. Entscheidend ist nicht, im Hosting-Menü möglichst schnell eine andere Zahl auszuwählen. Entscheidend ist, dass Kontaktformulare, Buchungen, Verwaltungsfunktionen und Hintergrundaufgaben nach dem Wechsel zuverlässig weiterarbeiten.
Dieser Leitfaden richtet sich an Unternehmen mit WordPress, WooCommerce oder einer individuell entwickelten PHP-Website. Er erklärt, welche Entscheidungen vor dem Update nötig sind und woran sich eine belastbare Abnahme erkennen lässt.
Was Ende 2026 tatsächlich endet
Die offizielle PHP-Supportübersicht unterscheidet aktive Pflege und eine anschließende Phase für Sicherheitskorrekturen. Für PHP 8.2 läuft diese letzte Phase am 31. Dezember 2026 aus. PHP 8.3 erhält laut derselben Übersicht Sicherheitskorrekturen bis Ende 2027, PHP 8.4 bis Ende 2028 und PHP 8.5 bis Ende 2029. Das sind Laufzeiten der jeweiligen Versionszweige, keine Zusage zur Kompatibilität Ihrer Website.
Eine Website schaltet sich am Stichtag nicht automatisch ab. Das Problem ist die weitere Pflege: Neu entdeckte Schwachstellen werden für einen abgekündigten Zweig vom PHP-Projekt nicht mehr regulär behoben. Manche Hoster bieten eigene verlängerte Pflege an. Lassen Sie sich deren konkreten Umfang schriftlich erläutern, statt einen Tarifnamen mit dem regulären PHP-Support gleichzusetzen.
Sicherheitskorrektur und Versionswechsel sind zwei Aufgaben
Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Sicherheitsupdates für mehrere gepflegte Zweige. Der Vorgang ist im PHP-Nachrichtenarchiv dokumentiert. Die praktische Konsequenz: Ein für Dezember geplanter größerer Versionswechsel ist kein Grund, notwendige Sicherheitskorrekturen bis dahin aufzuschieben. Lassen Sie den aktuellen Patchstand unabhängig von der Migration prüfen.
Ein Patch innerhalb eines Zweigs und der Wechsel von beispielsweise 8.2 auf 8.4 haben unterschiedliche Testumfänge. Trotzdem sollte auch ein Sicherheitsupdate anschließend an den wichtigsten Geschäftsabläufen kontrolliert werden. Bei einem konkreten Sicherheitsvorfall kommt außerdem die Prüfung auf bereits erfolgte Veränderungen hinzu; ein Update allein macht frühere Eingriffe nicht rückgängig.
Zuerst herausfinden, was auf dem Server wirklich läuft
Erstellen Sie eine kurze Bestandsaufnahme mit Ihrem Dienstleister. Darin stehen die PHP-Version der öffentlichen Website, die Version der Kommandozeile und die Umgebung zeitgesteuerter Aufgaben. Diese Angaben können voneinander abweichen. Ein funktionierendes Frontend beweist beispielsweise nicht, dass der nächtliche Rechnungsimport dieselbe Laufzeit verwendet.
- Anwendung: CMS-Version, Theme, Plugins, eigene Erweiterungen und verwendete Bibliotheken.
- Hosting: benötigte PHP-Erweiterungen, Speichergrenzen, Dateirechte und verfügbare Zielversionen.
- Anbindungen: E-Mail-Versand, Zahlung, CRM, Kalender, Datei- und PDF-Verarbeitung.
- Betrieb: Zuständigkeit, Sicherung, Wiederherstellung und ein geeigneter Umstellungszeitraum.
Bei WordPress ist die Kernsoftware nur ein Teil der Rechnung. Die WordPress-Dokumentation zur Serverumgebung hilft bei der Einordnung. Sie ersetzt aber keine Prüfung eines individuell programmierten Widgets oder eines älteren Plugins. Eine Erweiterung ohne nachvollziehbare Pflege ist ein gesonderter Befund, den ein PHP-Wechsel allein nicht löst.
Welche Zielversion ist sinnvoll?
Wählen Sie eine gepflegte Version, die Ihre vollständige Anwendung nachweislich unterstützt und die Ihr Hoster zuverlässig bereitstellt. Ein längerer verbleibender Supportzeitraum ist ein Vorteil. Er wiegt jedoch keine ungeklärten Fehler im Checkout oder im Kundenportal auf. Eine noch nicht freigegebene Vorabversion gehört nicht als ungeprüfte Abkürzung auf eine produktive Unternehmenswebsite.
Bei einem Sprung über mehrere Zweige müssen die relevanten Änderungen aller übersprungenen Versionen betrachtet werden. Die PHP-Migrationsleitfäden führen unter anderem inkompatible Änderungen und abgekündigte Funktionen auf. Daraus entsteht eine konkrete Prüfliste für den vorhandenen Code, keine pauschale Aussage „PHP ist abwärtskompatibel“.
Eine Testkopie muss die wichtigen Bedingungen abbilden
Für die Prüfung wird eine getrennte Umgebung mit vergleichbarer Konfiguration aufgebaut. Echte Zahlungen, Newsletter und Kundennachrichten bleiben dort deaktiviert oder auf sichere Testziele umgestellt. Vertrauliche Produktionsdaten werden nur verwendet, wenn das für den Test erforderlich und entsprechend geschützt ist. Eine ungeschützte Kopie mit echten Kontaktdaten wäre ein zusätzliches Problem.
Vor dem Wechsel werden Referenzfälle notiert: Welcher Nutzer kann welches Dokument sehen? Welche E-Mail entsteht nach einer Anfrage? Wie sieht ein korrekt erzeugtes PDF aus? Erst dann wird die Zielversion aktiviert. So lässt sich ein Unterschied der Laufzeit von einem bereits vorhandenen Fehler trennen.
Diese Abläufe gehören in die Abnahme
Ein sinnvoller Testfall nennt immer eine Ausgangslage, eine Handlung und ein erwartetes Ergebnis. Statt „Formular getestet“ steht beispielsweise: „Anfrage mit Umlauten und zulässigem Anhang abgesendet; genau ein Datensatz gespeichert; Nachricht im vorgesehenen Testpostfach angekommen; Bestätigung sichtbar.“ Das ist ein vorgeschlagenes Prüfmuster, kein Bericht über einen konkreten Kundenfall.
- Öffentliche Seiten: Startseite, wichtige Leistungen und Artikel ohne neue Fehlermeldungen aufrufen.
- Anfragen: gültige und ungültige Eingaben, Anhänge, Bestätigung und tatsächlichen Empfang prüfen.
- Verwaltung: Anmeldung, Rollen, Speichern, Vorschau und Bildverarbeitung durchspielen.
- Geschäftsprozesse: Buchung, Warenkorb, Testzahlung oder geschützten Download vollständig abschließen.
- Hintergrundarbeit: geplante Veröffentlichungen, Importe und periodische Aufgaben ausdrücklich ausführen.
- Technische Signale: Fehlerprotokolle, Antwortzeiten und auffällige Warnungen mit dem Ausgangsstand vergleichen.
Veraltete Funktionsaufrufe können zunächst nur Warnungen erzeugen. Trotzdem gehören sie in die Auswertung. Werden Warnungen im Browser ausgegeben, können sie außerdem JSON-Antworten oder Downloads beschädigen. Fehler sollten kontrolliert protokolliert werden, ohne Interna an Besucher auszugeben.
Der Rückweg braucht mehr als einen Schalter
Wenn ausschließlich die PHP-Laufzeit geändert wurde, kann eine Rückstellung genügen. Werden zugleich Plugins, Datenbankstrukturen oder Anwendungsdaten verändert, muss der Rückweg diese Änderungen berücksichtigen. Schreiben Sie vorab auf, welche Sicherung zu welchem Stand gehört und wie neue Anfragen oder Bestellungen während einer Rückabwicklung erhalten bleiben.
Für eine reine Informationswebsite lässt sich häufig ein kurzes ruhiges Wartungsfenster wählen. Bei einem Shop oder Buchungssystem muss zusätzlich geklärt sein, wann Schreibzugriffe stattfinden und wer nach der Umstellung prüft. Eine Sicherung ist erst überzeugend, wenn ihre Wiederherstellung einmal in einer getrennten Umgebung funktioniert hat.
Was Sie nach der Umstellung verlangen können
Eine brauchbare Übergabe nennt die neue Version, den geprüften Umfang, offene Ausnahmen und den Rückweg. Sie enthält außerdem eine Nachkontrolle auf dem tatsächlichen Hosting. URLs, Weiterleitungen und Indexierungsregeln sollten sich bei einem reinen PHP-Wechsel nicht beiläufig ändern. Prüfen Sie deshalb die wichtigsten Einstiegsseiten und Anfragewege erneut.
Ein guter nächster Schritt ist eine Bestandsaufnahme mit verbindlichem Testplan. Wenn Ihre Website individuell erweitert wurde, finden Sie im Beitrag über eigene WordPress-Plugins weitere Kriterien für deren Pflege. Über die Projektanfrage können Sie mir System, Hoster und geschäftskritische Funktionen nennen; daraus lässt sich ein sinnvoller Umfang für die technische Prüfung ableiten.
Quellenstand: 25. Oktober 2026. Supporttermine und Versionsinformationen stammen aus den verlinkten Herstellerquellen. Der Beitrag wurde KI-gestützt erarbeitet und anhand dieser Quellen geprüft.
