PHP 8.1 auf 8.4 migrieren, ohne dass die Seite ausfällt

Nach PHP2Shell wollen viele Unternehmen schnell auf eine gepatchte Fassung. Wer heute auf PHP 8.1 steht, hat dabei ein zusätzliches Problem: Für diesen Zweig erscheint überhaupt kein Patch mehr. Der Weg führt also nicht über ein Update, sondern über eine Migration. Dieser Beitrag beschreibt sie vollständig – was bricht, wie Sie es vorher herausfinden, und in welcher Reihenfolge Sie vorgehen, damit die Seite dabei nicht ausfällt.

Zuerst: Welches Ziel ist das richtige?

Die naheliegende Antwort „die nächstbeste unterstützte Version" ist hier die falsche. Ein Blick auf die Supportzeiträume des PHP-Projekts:

Daraus folgt ein Punkt, der in der aktuellen Aufregung untergeht: Wer jetzt auf 8.2 geht, kauft sich rund zehn Wochen. Ende Dezember 2026 endet auch dort der Sicherheitssupport, und dieselbe Migration steht erneut an.

Die sinnvolle Wahl ist 8.3 oder 8.4. 8.4 gibt Ihnen Sicherheitsupdates bis Ende 2028 und ist damit die Version, mit der Sie zwei Jahre Ruhe haben. 8.3 ist der kleinere Sprung, wenn die Anwendung alt ist und 8.4 zu viel auf einmal wäre.

8.5 ist jung. Für eine Firmenwebsite ohne besondere Anforderungen gibt es derzeit wenig Grund, ganz vorn zu stehen.

Unsere Empfehlung für den Normalfall: 8.4.

Was den Sprung von 8.1 überhaupt riskant macht

Zwischen 8.1 und 8.4 liegen drei Hauptversionen. Jede bringt Änderungen mit, die älteren Code zum Stolpern bringen. Die Sprünge sind dabei sehr unterschiedlich groß.

Der eigentliche Brocken: PHP 8.2

Dynamische Eigenschaften sind abgekündigt. Das ist die Änderung, an der die meisten alten Anwendungen hängen. Gemeint ist das hier:

```php class Kunde {} $k = new Kunde(); $k->alter = 30; // „alter" wurde nie deklariert ```

Bis 8.1 war das erlaubt und still. Seit 8.2 erzeugt es eine Abkündigungsmeldung, und ab PHP 9.0 wird daraus ein Fehler, der die Ausführung abbricht.

Der Grund für die Änderung ist einleuchtend: Ein Tippfehler beim Schreiben einer Eigenschaft fiel bisher niemandem auf. Wer `$k->alterr = 30` schrieb, legte stillschweigend eine zweite Eigenschaft an, und die Suche nach dem Fehler dauerte Stunden.

Drei Wege, damit umzugehen:

Weitere Abkündigungen in 8.2, die in älterem Code häufig vorkommen: die Zeichenketten-Einsetzung mit `${}`, die Funktionen `utf8_encode` und `utf8_decode`, sowie teilweise unterstützte Callable-Zeichenketten.

Der kleine Sprung: PHP 8.3

Vergleichsweise ruhig. Hier kommen vor allem neue Möglichkeiten hinzu, es fällt wenig weg. Wer von 8.2 nach 8.3 geht, hat erfahrungsgemäß wenig zu tun.

Der überschaubare Sprung: PHP 8.4

Die praktisch wichtigste Änderung sind implizit nullbare Parametertypen. Gemeint ist:

```php function f(string $name = null) { } // ab 8.4 abgekündigt function f(?string $name = null) { } // so ist es richtig ```

Das ist eine Schreibweise, die sich über Jahre eingebürgert hat und in sehr viel Code steckt. Die Korrektur ist mechanisch – ein Fragezeichen –, aber sie betrifft oft viele Stellen.

Der entscheidende Punkt: Abkündigung ist kein Fehler

Hier liegt das größte Missverständnis bei solchen Migrationen. Eine abgekündigte Funktion funktioniert weiter. Sie schreibt nur eine Meldung ins Protokoll.

Das hat zwei Folgen:

Die gute: Der Sprung auf 8.4 bringt Ihre Seite nicht zwangsläufig zum Absturz, nur weil irgendwo dynamische Eigenschaften benutzt werden. In vielen Fällen läuft alles weiter, und es füllen sich lediglich die Protokolle.

Die schlechte: Wenn die Fehleranzeige auf dem Server eingeschaltet ist, landen diese Meldungen mitten auf der Seite – über dem Kopfbereich, in der Mitte eines Formulars, im erzeugten PDF. Dann sieht es nach Totalausfall aus, obwohl nur eine Warnung ausgegeben wird.

Deshalb die wichtigste Einstellung vor jeder Migration: `display_errors` auf `Off`, `log_errors` auf `On`. Fehler gehören ins Protokoll, nicht auf die Seite. Auf einem Produktivsystem sollte das ohnehin so stehen.

Die Vorbereitung: herausfinden, was passiert

Raten Sie nicht. Es gibt drei Wege, das vorher zu klären, und sie kosten unterschiedlich viel.

Weg 1: Die Anwendung fragen

Die großen Systeme beantworten die Frage selbst. WordPress, TYPO3, Joomla, Drupal und die meisten Shops nennen in ihrer Dokumentation die unterstützten PHP-Versionen, oft auch im Verwaltungsbereich der Installation. Wenn Ihre Version 8.4 nicht unterstützt, ist das Ergebnis klar: Erst die Anwendung aktualisieren, dann PHP.

Diese Reihenfolge ist nicht verhandelbar. Eine alte Anwendung auf einer neuen PHP-Version ist genau der Fall, der Seiten weiß werden lässt.

Weg 2: Die Erweiterungen durchgehen

Hier steckt bei gewachsenen Websites der eigentliche Aufwand. Eine durchschnittliche WordPress-Installation bringt fünfzehn bis dreißig Erweiterungen mit, jede von jemand anderem entwickelt.

Gehen Sie die Liste durch und notieren Sie zu jeder: Wann kam das letzte Update? Wird die Erweiterung überhaupt noch gepflegt? Eine Erweiterung ohne Update seit zwei Jahren ist bei einem PHP-Sprung der wahrscheinlichste Kandidat für Ärger – und zugleich ein eigenes Sicherheitsthema.

Oft stellt sich dabei heraus, dass ein Drittel der Erweiterungen gar nicht mehr gebraucht wird. Die wegzuwerfen ist die billigste Vorbereitung, die es gibt.

Weg 3: Auf einem Testsystem laufen lassen

Der verlässlichste Weg und der, den wir empfehlen. Eine Kopie der Website auf einer Testumgebung mit PHP 8.4, dann die Protokolle ansehen.

Worauf Sie achten: Meldungen mit `Deprecated` sind Hinweise auf später, Meldungen mit `Fatal error` sind das, was die Seite wirklich bricht. Die zweite Sorte ist die, die Sie suchen – und wenn sie nicht auftritt, ist die Migration unkritisch.

Viele Hoster bieten solche Testumgebungen inzwischen auf Knopfdruck an. Falls nicht: Eine Kopie unter einer Unteradresse, für Suchmaschinen gesperrt, genügt.

Die Umstellung: Reihenfolge und Zeitpunkt

Schritt 1: Sichern

Dateien und Datenbank, außerhalb des Servers. Und zwar so, dass Sie die Sicherung auch zurückspielen können – eine Sicherung, die nie getestet wurde, ist eine Vermutung.

Schritt 2: Die Anwendung aktualisieren

Erst das System und die Erweiterungen auf einen Stand bringen, der 8.4 unterstützt. Danach prüfen, ob die Seite noch läuft. Dieser Schritt allein kann bei lange nicht gepflegten Installationen der größere Teil der Arbeit sein.

Schritt 3: Die PHP-Version umstellen

Bei Webhosting-Paketen ist das eine Einstellung im Kundenbereich, oft sofort wirksam. Auf eigenen Servern ist es mehr Arbeit, aber kein Projekt.

Ein Hinweis, der oft fehlt: Prüfen Sie, ob Ihr Server neben der Webserver-Version auch eine Befehlszeilen-Version von PHP hat. Zeitgesteuerte Aufgaben laufen darüber, und wenn dort weiterhin 8.1 steht, scheitern sie nach der Umstellung still. Das merkt man erst, wenn die nächtliche Sicherung nicht mehr läuft.

Schritt 4: Durchgehen, was ein Besucher tut

Nicht nur die Startseite. Die Wege, auf denen tatsächlich etwas passiert:

Schritt 5: Zwei Tage in die Protokolle sehen

Nicht nur direkt nach der Umstellung. Manche Abläufe laufen nur nachts, nur monatlich oder nur, wenn ein Kunde etwas Bestimmtes tut. Die Fehlerprotokolle der ersten 48 Stunden sagen mehr als jeder Test.

Wann umstellen?

Nicht Freitagnachmittag. Das ist keine Floskel, sondern folgt aus Schritt 5: Wenn nach der Umstellung zwei Tage lang jemand in die Protokolle sehen soll, muss dieser Jemand auch da sein.

Dienstag- oder Mittwochvormittag ist der ruhigste Zeitpunkt. Dann bleibt die ganze Woche, um Nachwirkungen zu bemerken.

Ausnahme: der aktuelle Fall. Wenn Sie heute auf PHP 8.1 stehen, läuft Ihre Website auf einer Fassung, für die es gegen PHP2Shell keinen Patch gibt und geben wird. Dann gilt die Reihenfolge nicht mehr: Erst die Seite vom Netz nehmen oder absichern, dann in Ruhe migrieren. Eine verwundbare Seite drei Wochen weiterlaufen zu lassen, weil die Migration geplant werden soll, ist die schlechtere Entscheidung.

Was Sie dabei gewinnen – außer Sicherheitsupdates

Zwei Dinge, die den Aufwand leichter begründbar machen:

Geschwindigkeit. Jede PHP-Hauptversion der letzten Jahre war schneller als ihre Vorgängerin. Zwischen 8.1 und 8.4 liegt bei typischen Anwendungen ein spürbarer Unterschied – ohne dass eine Zeile Code geändert werden muss.

Weniger Altlasten. Eine Migration zwingt dazu, die Liste der Erweiterungen einmal durchzugehen. Dieser Aufräumeffekt ist oft mehr wert als die Versionsnummer.

Wenn die Migration nicht geht

Es gibt Fälle, in denen der Weg versperrt ist: eine Fachanwendung, die der Hersteller nicht mehr pflegt; eine Eigenentwicklung, deren Programmierer nicht mehr erreichbar ist; ein Shop mit einer Anpassung, die niemand mehr versteht.

Dann bleiben drei Möglichkeiten, und alle drei sind unangenehm:

Bei einer reinen Firmenwebsite gibt es eine vierte: die Umstellung auf eine statische Fassung. Wo kein PHP läuft, stellt sich die Versionsfrage nicht mehr.

Checkliste: erste Schritte

Wie DAVINCI unterstützt

Wir stellen fest, welche PHP-Fassung Ihre Systeme wirklich nutzen, prüfen auf einem Testsystem, was der Sprung bricht, und führen die Migration so durch, dass es einen Rückweg gibt. Für eine schnelle erste Einordnung gibt es den kostenlosen PHP-Sicherheitscheck und den Quick-Check für 49 Euro. Den laufenden Betrieb übernehmen wir im Rahmen von IT-Betrieb und Support – Kontakt über die Kontaktseite.

Verwandte Themen: Wer hier weiterdenkt, liest bei TYPO3 ablösen, PHP2Shell betroffen und PHP-Sicherheitslücke weiter.