PHP 7.3 erschien im Dezember 2018 und wurde bis zum 6. Dezember 2021 gepflegt; das letzte Release war 7.3.33. Es ist die Version, auf der viele Projekte stehengeblieben sind, weil der nächste Schritt PHP 8.0 hieß und der sich nach Arbeit anhörte. Fünf Jahre später sind die Lücken seit Ende 2021 offen, einschließlich der beiden kritischen vom 21. Oktober 2026.
Wo PHP 7.3 heute steht
Hoster schalten 7.3 ab oder haben es bereits getan; manche bieten kostenpflichtigen Weiterbetrieb. Typische Stacks: Laravel 6 und 7, Symfony 4.4 und 5.0, TYPO3 9 und 10 LTS, Shopware 5.6, WordPress-Installationen mit alten Plugins, viele Eigenentwicklungen auf Composer-Basis. Das ist die gute Nachricht an 7.3: Composer ist meist vorhanden, das Framework hat einen Upgrade-Pfad, und E_DEPRECATED steht im Log.
Das Risiko liegt weniger im Code als in der Umgebung: Ein Server mit PHP 7.3 läuft fast immer auf einem Betriebssystem, das ebenfalls am Ende ist. Beim Upgrade wandert die Anwendung deshalb oft auf einen neuen Server, und beides zusammen ist ein Projekt.
Was beim Upgrade von 7.3 auf PHP 8 bricht
- Vergleiche zwischen Text und Zahl seit 8.0. Das ist der Bruch, der still passiert:
0 == "abc"ist falsch,switchauf gemischten Typen springt anders,in_array()ohne strikten Modus findet andere Treffer. - Fehler statt Warnungen. Interne Funktionen werfen seit 8.0
TypeErrorundValueError.count(null),strlen([]),array_key_exists()auf einem Objekt: In 7.3 ein Logeintrag, in 8.4 ein Abbruch. - PDO wirft Ausnahmen seit 8.0, mysqli seit 8.1. Code, der
if ($stmt === false)prüft, bekommt nie einfalsemehr, sondern eine Ausnahme, die niemand fängt. - Verschachtelte Ternär-Operatoren ohne Klammern sind seit 8.0 ein Fehler.
- match ist seit 8.0 reserviert, Ressourcen sind Objekte (cURL, GD, XML, OpenSSL, Zlib).
- Der Signatur-Wechsel bei implode(): Die Argumentreihenfolge (Trenner zuerst) ist seit 8.0 die einzige erlaubte.
- null an interne Funktionen ist seit 8.1 veraltet. In Formular-Code kommt
trim($_POST['x'] ?? null)an vielen Stellen vor. - Dynamische Eigenschaften seit 8.2,
${var}-Interpolation in Zeichenketten seit 8.2, implizit nullbare Parameter seit 8.4: alles noch Hinweise, aber jeder davon wird in einer kommenden Version ein Fehler. - Bibliotheken. Guzzle 6, PHPUnit 7 und 8, alte Doctrine- und Twig-Versionen, PHPExcel: Sie laufen nicht unter 8.4 und brauchen ein Update oder einen Ersatz.
Die vollständige Liste steht unter PHP 8 Breaking Changes. Wer den Sprung zu PHP 8.4 und seinen neuen Möglichkeiten machen will, findet dort, was danach besser wird.
Der Weg von 7.3 auf PHP 8.4
- Befund auf einer Kopie:
composer installunter 8.4 versuchen, PHPStan auf dem Code laufen lassen, die Testsuite unter 8.4 starten. Das Ergebnis ist die Liste der Arbeit. - Sicherheitsnetz um die Abläufe, deren Ausfall Geld kostet, soweit es noch fehlt.
- Abhängigkeiten zuerst: Composer-Pakete auf PHP-8-fähige Stände, Blocker ersetzen.
- Rector für das Mechanische, Handarbeit für Typ-Vergleiche, Datenbank-Fehlerbehandlung und null-Fälle. Strikte Typen einführen lohnt sich an den Stellen, die Rector anfasst.
- Umschalten mit Rückweg, bei Bedarf zusammen mit dem Serverwechsel.
Was so eine Migration an Zeit braucht und welche Risiken sie hat, steht in eigenen Beiträgen.
Für wen das nicht passt
Wer auf 7.3 ein Framework ohne Upgrade-Pfad betreibt, etwa CakePHP 2 oder Yii 1, braucht einen Ablöseplan statt eines PHP-Upgrades. Der erste Schritt bleibt derselbe: ein aktueller Interpreter unter dem alten Code, damit die Zeit bis zur Ablösung abgesichert ist.
