PHP 8 Breaking Changes: Die Migrations-Checkliste

Der Sprung von PHP 7.4 auf PHP 8 ist gut zu schaffen, wenn man weiß, wonach man sucht. Die meisten Probleme entstehen nicht durch exotische Sprachfeatures, sondern durch eine Handvoll Muster, die in altem Code besonders oft vorkommen. Dieser Artikel geht die wichtigsten durch und gibt eine Reihenfolge fürs Vorgehen.

Ein Hinweis vorweg: Fast alles hier findet man zuverlässiger mit statischer Analyse als durch Ausprobieren. Wer sich allein auf "einmal durchklicken" verlässt, übersieht genau die selten durchlaufenen Pfade, in denen es später knallt.

Aus Warnungen werden Fehler

Der folgenreichste Unterschied ist kein einzelnes Feature, sondern eine Haltung. PHP 8 nimmt viele Situationen ernst, die früher nur eine Warnung ausgelöst haben.

Falsche Typen an interne Funktionen führen jetzt zu einem TypeError statt zu einer Warnung mit stillem null als Rückgabe. Code, der jahrelang "funktioniert" hat, weil er Warnungen einfach ignorierte, kann in PHP 8 mit einem harten Fehler abbrechen. Das ist unangenehm, wenn es im Live-Betrieb passiert, und harmlos, wenn PHPStan es vorher gefunden hat.

Der @-Operator schluckt weniger

Das Unterdrückungszeichen @ verschluckt in PHP 8 keine fatalen Fehler mehr. Wo früher ein @ vor einem Aufruf auch einen schweren Fehler klaglos verschwinden ließ, etwa beim Aufruf einer nicht vorhandenen Funktion oder einem @include mit Parse-Fehler, kann jetzt ein Abbruch stehen. Solche Konstrukte sind in Legacy-Code weit verbreitet, oft als schnelle Notlösung von vor zehn Jahren. Die gehören alle einmal angeschaut.

Vergleiche zwischen String und Zahl

Das ist der subtilste Punkt, und der mit dem größten Ärgerpotenzial. Die Regeln für lose Vergleiche mit == zwischen Strings und Zahlen wurden korrigiert:

// PHP 7: true  (die 0 "gewinnt")
// PHP 8: false (korrekt)
0 == "foo";

Sachlich ist das eine deutliche Verbesserung. Nur kann es Logik brechen, die sich unbewusst auf das alte Verhalten verlassen hat. Gefährlich wird das, wenn so ein Vergleich in einer Berechtigungsprüfung oder einer Formularvalidierung steckt. Genau diese Stellen prüfen wir bei einer Migration von Hand, weil hier ein übersehener Fehler nicht nur einen Bug bedeutet, sondern ein Sicherheitsloch.

Entfernte und geänderte Funktionen

Ein paar lang abgekündigte Funktionen sind endgültig verschwunden:

• each() gibt es nicht mehr.
• create_function() ist weg, Closures übernehmen die Aufgabe.
• money_format() wurde entfernt.
• Etliche interne Funktionen haben strengere Signaturen bekommen.

Für jeden dieser Fälle gibt es einen klaren, modernen Ersatz. Die eigentliche Arbeit besteht nicht darin, den Ersatz zu kennen, sondern alle Fundstellen wirklich zu erwischen.

Was Sie im Gegenzug bekommen

Eine Migration ist kein reines Pflichtprogramm. PHP 8 bringt Werkzeuge, die den Code danach angenehmer zu warten machen. Constructor Property Promotion kürzt den ganzen Boilerplate in Klassen ein. Named Arguments machen Aufrufe mit vielen Parametern wieder lesbar. Match-Ausdrücke ersetzen die fehleranfälligen alten switch-Blöcke, und strengere Typisierung fängt Fehler ab, bevor sie in Produktion gehen. Man geht also nicht nur einem Risiko aus dem Weg, man bekommt auch etwas dafür.

Die Checkliste in sinnvoller Reihenfolge

1. Abhängigkeiten prüfen: Sind alle Composer-Pakete überhaupt PHP-8-tauglich?
2. Testabdeckung für die kritischen Pfade schaffen, solange noch alles läuft. Das ist das Netz für alles Weitere.
3. Statische Analyse einrichten, etwa PHPStan, und auf einem ordentlichen Level laufen lassen.
4. Die mechanischen Änderungen mit einem Werkzeug wie Rector automatisieren.
5. Die sicherheitsrelevanten Vergleiche und @-Stellen von Hand durchgehen.
6. Auf einer Staging-Umgebung mit PHP 8 testen, bevor es live geht.

Die Reihenfolge ist bewusst so gewählt: erst das Test-Netz, dann die Analyse, dann die Automatisierung. Wer mit Rector refaktoriert, bevor Tests grün sind, arbeitet ohne Sicherung. Die Schritte drei und vier nehmen den größten Teil der stumpfen Arbeit ab. Kopfzerbrechen bereiten am Ende nur die Stellen, an denen sich Geschäftslogik still auf altes Verhalten verlassen hat. Und die findet man mit Tests und Analyse, nicht mit Glück.

Kurz gesagt

Die Breaking Changes von PHP 8 sind zahlreich, aber überschaubar und gut dokumentiert. Wer der Reihe nach vorgeht, erst Analyse, dann Automatisierung, dann die riskante Handarbeit, macht aus der Migration ein planbares Projekt statt einer Zitterpartie. Wann sich der Aufwand lohnt, hängt meist am End-of-Life von PHP 7.4. Und ob Ihr Projekt eher ein Nachmittag oder ein mehrwöchiges Vorhaben ist, sagen wir Ihnen gern nach einem kurzen Blick in den Code.

Weiterführende Quellen

• PHP 8.0: Rückwärtsinkompatible Änderungen im Detail auf php.net
• Rector für automatisiertes Refactoring der mechanischen Änderungen
• PHPStan für die statische Analyse vor der Migration
• Im Ratgeber weiterlesen: Was kostet eine PHP-Migration?