PHP 7.0 erschien im Dezember 2015 und machte Anwendungen gegenüber 5.6 ungefähr doppelt so schnell. Deshalb wurde eifrig migriert, und deshalb liegt heute viel Code auf genau dieser Version: Die Migration von 5.6 war anstrengend, und danach hat man die Version nicht mehr angefasst. Seit dem 10. Januar 2019 gibt es keine Sicherheitsupdates mehr, das letzte Release war 7.0.33.
Wo PHP 7.0 heute steht
Sieben Jahre ohne Pflege. Alle Lücken, die seit 2019 im Interpreter gefunden wurden, sind offen, auch die beiden kritischen vom 21. Oktober 2026, die das PHP-Projekt nur für 8.2 bis 8.5 geschlossen hat. Hoster bieten 7.0 fast nirgends mehr an; wer noch darauf läuft, tut es meist auf einem eigenen Server, dessen Betriebssystem ebenfalls aus der Zeit stammt. Das ist der Fall, in dem die Anwendung gehackt wird und der Server zehn Jahre alt ist.
Das besondere Risiko von 7.0 gegenüber 7.4: Der Code hat die Warnungen nie gesehen, mit denen PHP zwischen 7.2 und 7.4 die späteren Brüche angekündigt hat. Ein leeres Fehlerlog auf 7.0 sagt nichts über die Kompatibilität mit PHP 8.
Was beim Upgrade von 7.0 auf PHP 8 bricht
- mcrypt wurde mit 7.2 aus dem Kern entfernt. Login-Routinen, Token-Verschlüsselung und Session-Handling aus der Zeit um 2016 nutzen es häufig. Ersatz ist OpenSSL oder Sodium, und die gespeicherten Daten müssen umgeschlüsselt werden.
- each(), create_function(), __autoload() sind seit 8.0 entfernt; auf 7.0 laufen sie ohne jede Meldung.
create_function()steckt gern in Sortier- und Template-Hilfsfunktionen. - Geschweifte Klammern für Offsets (
$str{0}) sind seit 8.0 ein Syntaxfehler. Die Datei lädt dann gar nicht mehr. - Vergleiche zwischen Text und Zahl verhalten sich seit 8.0 anders. Prüfungen wie
if ($id == "")oderin_array(0, $strings)kippen still. - Warnungen werden zu Fehlern. Interne Funktionen werfen seit 8.0
TypeErroroderValueError, wo 7.0 eine Warnung schrieb und weiterlief. Der Klassiker:count(null)oderstrlen()auf einem Array. - Verschachtelte Ternär-Operatoren ohne Klammern sind seit 8.0 ein Fehler. In Templates und Hilfsfunktionen von 2016 kommen sie vor.
- Reservierte Wörter.
matchist seit 8.0 ein Schlüsselwort. Eine Funktion oder Methode namensmatch()lädt nicht mehr. - Ressourcen sind Objekte. cURL-, GD- und XML-Handles sind seit 8.0 Objekte; Prüfungen mit
is_resource()schlagen fehl. - Dynamische Eigenschaften sind seit 8.2 veraltet, implizit nullbare Parameter (
Type $x = null) seit 8.4. Beides erzeugt Hinweise, die den Weg zur nächsten Version vorbereiten.
Die vollständige Liste steht im Beitrag PHP 8 Breaking Changes, die Werkzeuge zum Aufspüren unter Deprecated-Funktionen finden.
Der Weg von 7.0 auf PHP 8.4
- Bestandsaufnahme auf einer Kopie. Welche Erweiterungen, welche Bibliotheken, welches Framework in welcher Version. Bei 7.0 kommt fast immer ein Framework-Upgrade dazu, etwa von Symfony 2.8 oder von einem alten Laravel.
- Warnungen einsammeln. Die Testsuite einmal unter PHP 7.4 laufen lassen, um die Deprecations zu sehen, die 7.0 verschweigt. Das ist ein Werkzeugschritt, kein Zwischenziel.
- Sicherheitsnetz. Tests um Bestellung, Abrechnung, Import, Login, bevor eine Zeile geändert wird.
- Rector für das Mechanische, Handarbeit für mcrypt-Ersatz, Typ-Vergleiche und tote Bibliotheken.
- Umschalten mit Rückweg in einer Randzeit, alte Version bleibt zwei Wochen bereit.
Für wen das nicht passt
Wenn das Framework tot ist und keinen Upgrade-Pfad hat, ist die Frage nicht mehr PHP 8, sondern Modernisierung oder Neuentwicklung. Das klären wir im Befund, nicht erst in der Migration.
