Laravel und PHP 8: Kompatibilität herstellen

Eine Laravel-Anwendung, die seit Jahren zuverlässig Bestellungen abwickelt, Rechnungen schreibt oder Kundendaten verwaltet, ist kein Sanierungsfall. Sie ist der Beweis, dass die Fachlogik funktioniert. Und trotzdem landet früher oder später jeder vor derselben Wand: Der Hoster kündigt das Ende von PHP 7.4 an, oder eine neue Bibliothek verlangt PHP 8. Plötzlich steht die Frage im Raum, ob die Anwendung den Sprung überlebt.

Die gute Nachricht vorweg: In den allermeisten Fällen ist die Migration von Laravel auf PHP 8 deutlich harmloser, als der erste Blick auf die Fehlerausgabe vermuten lässt. Das Problem ist selten die Geschäftslogik. Es ist der Code drumherum – abgekündigte Funktionen, geänderte Typregeln und ein paar Pakete, die den Anschluss verpasst haben.

Was sich zwischen PHP 7.4 und PHP 8 wirklich geändert hat

Bevor Sie eine Zeile Code anfassen, sollten Sie wissen, wo die Reibung entsteht. PHP 8.0 hat einige Verschärfungen mitgebracht, die alten Code stolpern lassen:

• Strengere Typprüfung bei internen Funktionen. Wo PHP 7 aus einem null stillschweigend einen leeren String machte, wirft PHP 8.1+ eine Deprecation-Warnung. Klassiker: strlen(null), trim(null) oder str_replace mit einem null-Wert aus der Datenbank.
• Fehler statt Warnungen. Viele frühere Warnings sind jetzt TypeError oder Error. Ein Ausdruck wie "5" + "3 Äpfel" verhält sich anders und kann Ausnahmen auslösen.
• Reservierte Schlüsselwörter. match ist seit PHP 8 ein Sprachkonstrukt. Wenn Sie irgendwo eine Methode oder Funktion match() genannt haben, bricht das.
• Geänderte Sortier-Stabilität. sort(), usort() und Co. sind seit PHP 8 stabil. Das ist eine Verbesserung, kann aber Ausgaben verändern, die vorher zufällig anders sortiert waren – ein Detail, das gerne in Tests auffällt.

Das klingt nach viel, betrifft in der Praxis aber meist eine überschaubare Zahl konkreter Stellen. Der Punkt ist: Diese Stellen muss man finden, nicht erraten.

Die richtige Reihenfolge: Erst Laravel, dann PHP – oder umgekehrt?

Ein häufiger Fehler ist, PHP 8 und ein Laravel-Upgrade gleichzeitig anzugehen. Damit vermischen Sie zwei Fehlerquellen und wissen bei jedem Absturz nicht, wer schuld ist. Trennen Sie die Schritte.

Prüfen Sie zuerst, welche Laravel-Version Sie fahren. Laravel und PHP 8 vertragen sich erst ab bestimmten Versionen sauber: Laravel 8 unterstützt PHP 8.0, Laravel 9 setzt PHP 8.0 voraus und läuft bis 8.2, Laravel 10 verlangt mindestens PHP 8.1. Wenn Sie auf Laravel 6 oder 7 sitzen, führt der saubere Weg über ein schrittweises Framework-Upgrade – eine Version nach der anderen, nicht im Sprung.

Meine praktische Empfehlung: Bringen Sie das Framework zunächst auf die höchste Version, die noch mit Ihrer aktuellen PHP-Version läuft. Stabilisieren Sie das. Erst dann heben Sie PHP an. So bleibt jeder Schritt einzeln testbar und rückrollbar.

Kompatibilität für Laravel und PHP 8 systematisch aufdecken

Raten ist der teuerste Teil jeder Migration. Nutzen Sie stattdessen Werkzeuge, die Ihnen die problematischen Stellen schwarz auf weiß liefern:

• PHPCompatibility (ein Ruleset für PHP_CodeSniffer). Damit scannen Sie Ihren gesamten Code gegen eine Zielversion: phpcs -p ./app --standard=PHPCompatibility --runtime-set testVersion 8.1. Das Ergebnis ist eine Liste konkreter Dateien und Zeilen.
• Rector mit dem Set LevelSetList::UP_TO_PHP_81. Rector findet nicht nur Probleme, sondern kann viele davon automatisiert umschreiben. Lassen Sie es zuerst im Dry-Run laufen (vendor/bin/rector process --dry-run) und prüfen Sie jeden vorgeschlagenen Change, bevor Sie ihn übernehmen.
• PHPStan oder Larastan. Statische Analyse deckt genau die impliziten null-Übergaben und Typkonflikte auf, die PHP 8 zur Laufzeit bestraft. Wenn Ihr Projekt hier noch keine Baseline hat, ist jetzt der beste Zeitpunkt.

Der Wert dieser Werkzeuge liegt nicht nur im Finden. Sie verwandeln ein diffuses Risiko in eine abarbeitbare Aufgabenliste. Das ist der Unterschied zwischen einer planbaren Migration und einem Wochenende voller Überraschungen.

Die Abhängigkeiten sind der eigentliche Engpass

In der Regel ist nicht Ihr eigener Code das größte Hindernis, sondern composer.json. Alte Pakete deklarieren oft "php": "^7.2" und blockieren damit das gesamte Update. Gehen Sie die Liste systematisch durch:

• composer why-not php 8.1 zeigt Ihnen exakt, welches Paket den Aufstieg verhindert.
• Prüfen Sie für jedes blockierende Paket, ob eine neuere Version PHP 8 unterstützt. Meistens ja – Sie hängen nur an einer veralteten Version fest.
• Für unmaintainte Pakete gibt es oft aktive Forks oder einen schlanken Ersatz. Manchmal ist die ehrlichste Lösung, ein winziges Paket durch zwanzig Zeilen eigenen Code zu ersetzen.

Fahren Sie das Ganze bewusst auf einem separaten Branch und mit einer Kopie der Produktionsdatenbank. Composer-Konflikte löst man nicht unter Zeitdruck auf dem Live-System.

Testen, bevor Sie es glauben

Der beste Schutz bei einer PHP-8-Migration ist eine Testsuite. Haben Sie keine, ist das kein Grund zur Panik, aber ein Grund für Vorsicht. Schreiben Sie zumindest ein paar Feature-Tests für die kritischen Pfade – Login, Bestellung, Rechnungserzeugung – bevor Sie migrieren. Diese Tests sind ohnehin eine Investition, die sich über jede zukünftige Änderung hinweg auszahlt.

Aktivieren Sie während der Migration APP_DEBUG=true in einer Staging-Umgebung und lassen Sie sich alle Deprecations anzeigen. Viele Probleme melden sich als Warnung, lange bevor sie zu echten Fehlern werden. Wer diese Signale ernst nimmt, migriert einmal sauber statt dreimal hektisch.

Ein ehrliches Wort zum Schluss

Es gibt eine verführerische Stimme, die bei jedem Migrationsschmerz flüstert: "Lass uns das doch gleich neu bauen." In den meisten Fällen ist das die teuerste und riskanteste Option, die es gibt. Sie werfen funktionierende, über Jahre gehärtete Fachlogik weg, um sie mühsam nachzubauen – inklusive aller Sonderfälle, an die sich niemand mehr erinnert. Eine PHP-8-Migration kostet Tage bis wenige Wochen. Eine Neuentwicklung kostet Monate und ein neues Risiko.

Praxis-Tipp: Fangen Sie klein an. Klonen Sie das Projekt, lassen Sie PHPCompatibility und composer why-not laufen und schauen Sie sich die Liste an. In neun von zehn Fällen werden Sie überrascht sein, wie kurz sie ist. Erst dann entscheiden Sie über den Aufwand – auf Basis von Fakten, nicht von Bauchgefühl. Wenn Sie bei genau diesem Schritt eine zweite Meinung oder Verstärkung brauchen, ist das eine der Aufgaben, bei denen LegacyWerk regelmäßig unterstützt.