PHP-Versionen — was noch sicher ist und was nicht.

Der Stand.

Stand der Recherche: Oktober 2026, nach den Angaben des PHP-Projekts. Die Tabelle gilt für das offizielle PHP; manche Linux-Distributionen und Hoster pflegen ältere Versionen länger mit eigenen Korrekturen.

Wie der Lebenszyklus funktioniert.

Jedes Jahr gegen Ende November erscheint eine neue PHP-Version. Sie bekommt zwei Jahre lang aktive Pflege mit Fehlerkorrekturen und danach zwei weitere Jahre nur Sicherheitskorrekturen. Insgesamt also rund vier Jahre.

Das heißt praktisch: Wer eine Version beim Erscheinen einsetzt, hat Zeit. Wer erst spät wechselt, hat oft nur noch ein oder zwei Jahre, bevor der nächste Wechsel ansteht. Für Anwendungen mit eigenem Code lohnt es sich, nicht auf die älteste noch unterstützte Version zu setzen, sondern auf eine der neueren.

Was das Ende bedeutet.

Eine PHP-Version ohne Support läuft weiter. Nichts schaltet sich ab. Das macht es gefährlich bequem.

Was sich ändert: Neu entdeckte Sicherheitslücken in PHP selbst werden für diese Version nicht mehr geschlossen. Dazu kommt, dass Erweiterungen und Frameworks die alte Version nach und nach nicht mehr unterstützen — neue Plugin-Versionen setzen eine neuere PHP-Version voraus, und man bleibt auf alten Ständen hängen, die ihrerseits Lücken haben (Sicherheit).

Für Websites mit Formularen, Kundenkonten oder Zahlungen ist das ein echtes Risiko. Und für Unternehmen mit Datenschutzpflichten ist es schwer zu begründen, warum ein bekannt veraltetes System weiterbetrieben wird.

Was Hoster machen.

Hoster gehen unterschiedlich damit um. Manche stellen veraltete Versionen automatisch auf eine neuere um — mit Vorankündigung per Mail, die oft untergeht. Andere bieten alte Versionen gegen Aufpreis weiter an, teils mit eigenen Sicherheitskorrekturen.

Die automatische Umstellung ist der Moment, in dem viele Websites plötzlich Fehler zeigen: Der Hoster stellt um, ein altes Plugin oder eigener Code ist nicht verträglich, und die Website zeigt eine weiße Seite (Fehler nach PHP-Update).

Besser ist, selbst zu wechseln, bevor der Hoster es tut — in Ruhe, mit Test.

Welche Version läuft bei mir?

Im Kundenbereich des Hosters steht die eingestellte PHP-Version, oft je Domain oder Verzeichnis. In WordPress zeigt der Bereich zum Website-Zustand die Version an. In anderen Systemen gibt es ähnliche Übersichten.

Wichtig: Die Version für die Website und die Version auf der Kommandozeile können sich unterscheiden. Wer Abhängigkeiten über die Kommandozeile installiert oder Cronjobs nutzt, sollte beide prüfen.

Was die Systeme verlangen.

Die großen Systeme heben ihre Mindestanforderungen regelmäßig an. Laravel 13 etwa setzt PHP 8.3 voraus, Shopware 6.7 PHP 8.2 (Laravel aktualisieren, Shopware-Update). WordPress läuft auf einer breiten Spanne von Versionen, empfiehlt aber eine aktuelle.

Für eigene Anwendungen gilt: Die Abhängigkeiten bestimmen, was geht. Eine alte Bibliothek, die nicht mehr gepflegt wird, kann einen ganzen Versionssprung blockieren.

Den Wechsel planen.

1. Bestandsaufnahme: aktuelle Version, Erweiterungen, eigener Code, Abhängigkeiten.
2. Zielversion wählen — nicht die älteste noch unterstützte, sondern eine mit Puffer.
3. Kompatibilität prüfen: Erweiterungen auf Unterstützung, eigenen Code mit Analysewerkzeugen.
4. Testumgebung mit der Zielversion einrichten (Staging).
5. Fehlerprotokoll aktivieren und alle wichtigen Funktionen durchklicken.
6. Anpassen, was nicht läuft.
7. Live umstellen, Protokoll beobachten.

Typische Fehler beim Wechsel.

• Entfernte Funktionen: Alte Funktionen, die über Jahre als veraltet markiert waren, gibt es nicht mehr.
• Strengere Typen: Was früher eine Warnung war, ist jetzt ein Fehler.
• Dynamische Eigenschaften: Seit PHP 8.2 als veraltet gemeldet — betrifft viel älteren objektorientierten Code.
• Null-Werte an Funktionen, die Text erwarten — massenhaft Hinweise im Protokoll.
• Veraltete Bibliotheken im eigenen Projekt.

Viele dieser Meldungen sind zunächst nur Hinweise, die nichts kaputtmachen. Sie zeigen aber, was beim nächsten Sprung zum Fehler wird. Wer sie jetzt behebt, hat es beim nächsten Wechsel leichter (PHP 7 auf 8).

Wenn der Code nicht mitkommt.

Manchmal lässt sich eine Anwendung nicht ohne Weiteres auf eine neue Version bringen — etwa weil sie auf einem veralteten Framework basiert oder der Code so alt ist, dass vieles angefasst werden müsste.

Dann gibt es drei Wege: den Code schrittweise modernisieren, die Anwendung neu bauen oder sie übergangsweise isoliert betreiben, bis eine Lösung steht. Welcher Weg sinnvoll ist, hängt vom Umfang und vom Wert der Anwendung ab (Altprojekt modernisieren).

Wenn du nicht weiterkommst.

Wenn deine Website oder Anwendung auf einer alten PHP-Version läuft und du den Wechsel sicher planen willst. Ich sehe mir den Code an, sage dir, wo die Risiken liegen, und setze um, was nötig ist. Die Übersicht findest du unter PHP und Laravel; wenn es eilt, hilft der Notfall-Support.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. PHP ist die Sprache, in der ich seit Jahren am meisten Code schreibe — in WordPress-Plugins, Shop-Erweiterungen, Schnittstellen und eigenständigen Anwendungen mit Laravel. Ich unterrichte Webentwicklung als Dozent und kenne PHP vom alten prozeduralen Skript bis zur modernen, typisierten Anwendung mit Tests.

Gerade bei bestehenden Anwendungen zählt das: Ich lese fremden Code schnell, erkenne, wo er gegen die Sprache arbeitet, und sehe, was sich mit vertretbarem Aufwand retten lässt. Viele PHP-Projekte, die als hoffnungslos gelten, sind es nicht — sie wurden nur lange nicht gepflegt.

Was du bekommst: eine ehrliche Einschätzung, ob sich modernisieren oder neu bauen lohnt, sauberen Code, den auch andere Entwickler verstehen, und eine Dokumentation — auch wenn die Antwort lautet, dass die Anwendung so bleiben kann.