PHP 7.2 erschien im November 2017 und war drei Jahre lang die Arbeitsversion vieler Shops und Agentur-Projekte. Seit dem 30. November 2020 gibt es keine Sicherheitsupdates mehr; das letzte Release war 7.2.34. Mit 7.2 verschwand mcrypt aus dem Kern, und each() sowie create_function() wurden als veraltet markiert. Wer das Log gelesen hat, kennt seine Baustellen für PHP 8 bereits.
Wo PHP 7.2 heute steht
Sechs Jahre ohne Pflege. Alle seit Ende 2020 gefundenen Lücken im Interpreter sind offen, auch die beiden kritischen vom 21. Oktober 2026, für die es nur Fixes ab 8.2 gab. Viele Hoster haben 7.2 bereits abgeschaltet; die verbliebenen Installationen laufen auf eigenen Servern oder bei Hostern mit kostenpflichtigem Weiterbetrieb.
Typische Stacks: Shopware 5.4 bis 5.6, Magento 2.2 und 2.3, TYPO3 9 LTS, Drupal 8, Laravel 5.6 bis 5.8, Symfony 4.0 bis 4.3. Mehrere davon haben eigene Support-Enden, die für den Weg wichtiger sind als die PHP-Version: Für Shopware 5, Magento 1 und TYPO3 in alten LTS-Versionen gibt es jeweils eine eigene Seite mit den Optionen.
Was beim Upgrade von 7.2 auf PHP 8 bricht
- each(), create_function(), __autoload() sind seit 8.0 entfernt. Unter 7.2 melden sie sich als Deprecation, wenn
E_DEPRECATEDim Log landet. Oft ist genau das abgeschaltet. - Geschweifte Klammern für Offsets sind seit 8.0 ein Syntaxfehler.
$str{0}muss zu$str[0]werden. - Vergleiche zwischen Text und Zahl haben sich mit 8.0 geändert.
0 == "abc"ist falsch,"1" == "01"bleibt wahr,"abc" == 0ist falsch. Formularprüfungen und Statusvergleiche kippen leise. - Interne Funktionen werfen Fehler statt Warnungen.
count()aufnull,array_merge()mit einem Nicht-Array,strpos()mit falschem Typ: In 7.2 eine Warnung, in 8.4 ein Abbruch. - Verschachtelte Ternär-Operatoren ohne Klammern sind seit 8.0 nicht mehr erlaubt.
- match ist seit 8.0 reserviert.
- Ressourcen sind Objekte seit 8.0. Prüfungen mit
is_resource()auf cURL- oder GD-Handles schlagen fehl. - PDO und mysqli melden Fehler als Ausnahme. PDO seit 8.0, mysqli seit 8.1. Code, der auf
falseals Rückgabewert prüft, bekommt stattdessen eine unbehandelte Ausnahme. - null an interne Funktionen ist seit 8.1 veraltet, dynamische Eigenschaften seit 8.2, implizit nullbare Parameter seit 8.4.
Die vollständige Liste steht unter PHP 8 Breaking Changes. Für die Suche im eigenen Code: Deprecated-Funktionen finden.
Der Weg von 7.2 auf PHP 8.4
- Befund auf einer Kopie. Dazu gehört bei 7.2 der Blick auf das System darunter: Shop, CMS oder Framework haben eigene Fristen.
- Sicherheitsnetz. Tests um Bestellung, Zahlung, Export, Login. Wie man Tests in Code ohne Tests einführt, steht im eigenen Beitrag.
- Abhängigkeiten aktualisieren. Composer-Abhängigkeiten auf PHP-8-fähige Stände bringen, Blocker ersetzen.
- Rector für das Mechanische, Handarbeit für Typ-Vergleiche, Fehlerbehandlung an der Datenbank und tote Bibliotheken.
- Umschalten in Etappen, mit Rückweg.
Für wen das nicht passt
Ein Shop, der in sechs Monaten auf ein anderes System wechselt, braucht bis dahin einen abgesicherten Weiterbetrieb, keine Migration. Was das heißt, steht auf der Seite zur jeweiligen Situation. Wenn die Anwendung dagegen bleiben soll, ist das PHP-Upgrade der erste Schritt, nicht der letzte.
