PHP 8.4 erschien am 21. November 2024. Es wird bis zum 31. Dezember 2026 aktiv gepflegt und bekommt danach Sicherheitsupdates bis zum 31. Dezember 2028. Das Sicherheitsrelease vom 21. Oktober 2026 war 8.4.27.
Warum 8.4 unser Standardziel ist
Wer eine Anwendung von PHP 5.6 oder 7.x migriert, will danach Ruhe haben. 8.4 liefert sie: zwei Jahre bis zum nächsten Pflichttermin, breite Unterstützung bei Hostern, alle großen Frameworks und Bibliotheken seit Ende 2024 kompatibel, Rector und PHPStan kennen jede Regel. 8.5 hat ein Jahr mehr Laufzeit, aber eine jüngere Umgebung; für eine Migration aus alter Zeit zählt die Reife der Umgebung mehr als das Jahr.
Die Pflege-Regel des PHP-Projekts seit 2024: zwei Jahre aktiver Support, dann zwei Jahre Sicherheitsupdates, beide Termine am Jahresende. Damit lässt sich planen: Wer auf 8.4 geht, hat das nächste Upgrade für 2028 im Kalender, nicht als Überraschung.
Was 8.4 Neues bringt
- Property Hooks: Getter und Setter direkt an der Eigenschaft. Modellklassen verlieren die Hälfte ihrer Zeilen.
- Asymmetrische Sichtbarkeit:
public private(set), lesbar von außen, schreibbar nur innen. Ersetzt viele readonly-Umgehungen. newohne Klammern beim Methodenaufruf auf dem neuen Objekt.- Neue DOM-API (
Dom\HTMLDocument) mit HTML5-Parser, ein Ersatz für die alten Workarounds beim Parsen von HTML. - array_find(), array_any(), array_all() und ein paar weitere Array-Hilfen.
- Lazy Objects im Kern, nützlich für ORMs und Proxies.
Was 8.4 im Detail bringt, steht im eigenen Beitrag.
Was 8.4 von älterem Code verlangt
Von 8.3 kommend wenig: implizit nullbare Parameter umschreiben, E_STRICT entfernen, Rundungen testen, veraltete mysqli- und xml-Funktionen ersetzen. Von 8.0 bis 8.2 kommend zusätzlich die Deprecations der Zwischenversionen (null an interne Funktionen, dynamische Eigenschaften, Interpolation). Von 7.x oder 5.6 kommend die ganze Liste von PHP 8 Breaking Changes. Was im Einzelfall gilt, steht auf der Seite zur Ausgangsversion; die Übersicht ist unten verlinkt.
Nach dem Upgrade: die Routine
Ein Patch-Release alle vier Wochen, meist ohne Verhaltensänderung, in Minuten eingespielt. Wer das als Routine aufbaut (wer spielt ein, wer testet, wie wird es nachgewiesen), hat das Thema dauerhaft erledigt. Wie man den Patch-Stand belegt, wenn Kunde, Versicherer oder Audit fragen, und was ein Sicherheitsrelease auslöst, zeigen zwei Beiträge vom Oktober 2026.
Für die weitere Modernisierung nach dem Versionssprung: strikte Typen einführen, Abhängigkeiten im Griff behalten, Tests nachrüsten.
