PHP 7.4 erschien im November 2019 und ist die letzte Version der 7er-Reihe. Seit dem 28. November 2022 gibt es keine Sicherheitsupdates mehr; das letzte Release war 7.4.33. Es ist die am weitesten verbreitete Altversion: Die meisten Anfragen, die uns mit einer Hoster-Frist erreichen, betreffen 7.4.
Wo PHP 7.4 heute steht
Vier Jahre ohne Pflege. Alle seit Ende 2022 gefundenen Lücken im Interpreter sind offen, einschließlich der beiden kritischen vom 21. Oktober 2026 (Codeausführung ohne Anmeldung), die das PHP-Projekt nur für 8.2 bis 8.5 geschlossen hat. Einige Distributionen und kommerzielle Anbieter liefern Backports für 7.4; wer darauf setzt, muss das pro Server nachweisen können.
Die Hoster haben reagiert: 7.4 wird abgeschaltet, auf eine neuere Version zwangsumgestellt oder nur noch gegen Aufschlag angeboten. Die Mail dazu kommt mit Frist, oft an die Rechnungsadresse. Was dann in welcher Reihenfolge zu tun ist, steht auf der Seite zur Hoster-Frist. Warum das Support-Ende mehr als ein Hosting-Thema ist, im Beitrag zum 7.4-EOL.
Typische Stacks: Laravel 8, Symfony 5.x, TYPO3 10 und 11, Shopware 5.7, Magento 2.4, WordPress und Drupal 9 mit alten Plugins, viele Composer-basierte Eigenentwicklungen.
Was beim Upgrade von 7.4 auf PHP 8 bricht
Von 7.4 aus ist der Sprung technisch der kleinste unter den 7er-Versionen, aber die Brüche von 8.0 sind alle noch vor Ihnen:
- Vergleiche zwischen Text und Zahl.
0 == "abc"ist seit 8.0 falsch. Prüfungen auf leere Eingaben,switch-Blöcke mit gemischten Typen undin_array()ohne strikten Modus verhalten sich anders, ohne Fehlermeldung. - Fehler statt Warnungen. Interne Funktionen werfen
TypeErroroderValueError, wo 7.4 eine Warnung ins Log schrieb. Das trifftcount(),strlen(),array_*-Funktionen mit falschen Typen. - PDO meldet Fehler seit 8.0 als Ausnahme, mysqli seit 8.1. Code, der Rückgabewerte auf
falseprüft, bekommt unbehandelte Ausnahmen. - Verschachtelte Ternär-Operatoren ohne Klammern sind ein Fehler, match ist reserviert, Ressourcen sind Objekte.
- null an interne Funktionen ist seit 8.1 veraltet:
trim(null),strlen(null),htmlspecialchars(null). In Formular- und Template-Code hundertfach. - Dynamische Eigenschaften seit 8.2,
${var}-Interpolation seit 8.2, utf8_encode/utf8_decode seit 8.2, implizit nullbare Parameter (Type $x = null) seit 8.4. Noch Hinweise, in einer kommenden Version Fehler. - Bibliotheken: Guzzle 6, PHPUnit 8 und 9.0, Monolog 1, Carbon 1, alte Doctrine-Versionen. Fast immer gibt es ein Update, selten einen Ersatz.
Die vollständige Liste steht unter PHP 8 Breaking Changes. Was sich zwischen 8.0, 8.1, 8.2 und 8.3 jeweils geändert hat, im Vergleichsbeitrag.
Der Weg von 7.4 auf PHP 8.4
- Befund auf einer Kopie:
composer installunter 8.4, PHPStan, Testsuite. Zwei bis drei Werktage, Ergebnis ist die Liste der Arbeit und der Festpreis. - Sicherheitsnetz, soweit Tests fehlen: um Bestellung, Abrechnung, Import, Login.
- Abhängigkeiten aktualisieren, Blocker ersetzen.
- Rector für das Mechanische, Handarbeit für Typ-Vergleiche, Datenbank-Fehlerbehandlung, null-Fälle.
- Umschalten in einer Randzeit, mit Rückweg. Die Umschaltung selbst ist ein Versionswechsel am Server, bei Bedarf in Minuten rückgängig.
Je nach Größe zwei bis sechs Wochen, parallel zum Betrieb. Woran die Dauer hängt, welche Risiken auftreten und wie ein Rückweg aussieht, beschreiben eigene Beiträge.
Für wen das nicht passt
Eine Anwendung, die weniger wert ist als die Migration, bekommt im kostenlosen Kurz-Check genau diese Auskunft. Dann geht es um einen abgesicherten Weiterbetrieb bis zur Ablösung, nicht um ein Upgrade.