PHP 7.1 erschien im Dezember 2016 und wurde drei Jahre gepflegt. Seit dem 1. Dezember 2019 gibt es keine Sicherheitsupdates mehr; das letzte Release war 7.1.33. Es war die letzte Version, in der die mcrypt-Erweiterung noch zum Kern gehörte, und die erste mit nullbaren Typen und void. Beides prägt den Code, der heute noch darauf läuft.
Wo PHP 7.1 heute steht
Fast sieben Jahre ohne Pflege. Jede seit Ende 2019 gefundene Lücke ist offen, einschließlich der beiden kritischen vom 21. Oktober 2026, die nur für 8.2 bis 8.5 geschlossen wurden. Hoster haben 7.1 aus dem Angebot genommen; die typische 7.1-Anwendung läuft heute auf einem eigenen oder gemieteten Server mit einem Betriebssystem aus derselben Zeit.
Typische Stacks dieser Generation: Symfony 3.4 und frühe 4er, Laravel 5.5 und 5.6, Shopware 5.3 bis 5.5, TYPO3 8 LTS, Drupal 8. Alle diese Framework-Versionen sind ebenfalls ohne Support. Deshalb ist bei 7.1 das Framework-Upgrade fast immer Teil des Projekts.
Was beim Upgrade von 7.1 auf PHP 8 bricht
- mcrypt ist seit 7.2 weg. In 7.1-Anwendungen steckt es in Login, Token und API-Signaturen. Ersatz: OpenSSL oder Sodium, mit Umschlüsselung der Bestände.
- each(), create_function(), __autoload() wurden in 7.2 als veraltet markiert und in 8.0 entfernt. Auf 7.1 laufen sie ohne Meldung.
- Geschweifte Klammern für Offsets sind seit 8.0 ein Syntaxfehler.
- Vergleiche zwischen Text und Zahl verhalten sich seit 8.0 anders. Alte Eingabeprüfungen kippen leise.
- Interne Funktionen werfen Fehler statt Warnungen seit 8.0. Was in 7.1 ein Eintrag im Log war, ist in 8.4 eine abgebrochene Anfrage.
- Verschachtelte Ternär-Operatoren ohne Klammern sind seit 8.0 nicht mehr erlaubt.
- match ist seit 8.0 reserviert; eine eigene Funktion
match()lädt nicht mehr. - Ressourcen sind Objekte seit 8.0 (cURL, GD, XML, OpenSSL);
is_resource()schlägt fehl. - null an interne Funktionen mit nicht nullbaren Parametern ist seit 8.1 veraltet.
strlen(null),trim(null),htmlspecialchars(null)erzeugen Hinweise, bald Fehler. In 7.1-Code mit vielen Formularen kommt das hundertfach vor. - Dynamische Eigenschaften sind seit 8.2 veraltet, implizit nullbare Parameter seit 8.4.
Die Liste der Brüche steht im Beitrag PHP 8 Breaking Changes; wie man die Deprecations im eigenen Code findet, im Beitrag dazu. Wer wissen will, was sich zwischen 8.0 und 8.3 geändert hat, findet dort die Zwischenschritte.
Der Weg von 7.1 auf PHP 8.4
- Befund auf einer Kopie: Erweiterungen, Bibliotheken, Framework, Testlage, erreichbarer Code.
- Sicherheitsnetz: Tests um die Abläufe, deren Ausfall Geld kostet.
- Abhängigkeiten zuerst. Composer einführen, falls nicht vorhanden (so geht das), dann jede Bibliothek auf einen PHP-8-fähigen Stand oder Ersatz bringen. Erst wenn
composer installunter 8.4 durchläuft, lohnt sich der Rest. - Rector für das Mechanische, Handarbeit für mcrypt, Typ-Vergleiche und null-Behandlung.
- Umschalten mit Rückweg, zwei Wochen Parallelbereitschaft der alten Version.
Wie lange eine solche Migration dauert und welche Risiken dabei auftreten, beschreiben eigene Beiträge.
Für wen das nicht passt
Wenn das Framework keinen Upgrade-Pfad mehr hat und die Anwendung groß ist, wird aus dem PHP-Upgrade eine schrittweise Ablösung nach dem Strangler-Fig-Muster. Auch dann ist der erste Schritt ein aktueller Interpreter unter dem alten Code, damit die Zeit bis zur Ablösung abgesichert ist.
