Wenn ein System seit Jahren zuverlässig Rechnungen schreibt, Bestellungen verarbeitet oder Termine verwaltet, dann ist das kein Kandidat für den Mülleimer. Es ist der Beweis, dass die Fachlogik funktioniert. Das Problem sitzt fast immer im Code drumherum: in der veralteten PHP-Version, in fehlenden Typen, in einer DOM-Verarbeitung, die HTML5 nie richtig verstanden hat. Genau hier setzt PHP 8.4 an. Die Frage ist nicht, ob Sie jedes neue Feature nutzen, sondern welche PHP 8.4 Features Ihnen bei der Wartung eines bestehenden Projekts tatsächlich Arbeit abnehmen.
Ich gehe die Neuerungen aus der Perspektive durch, die für Bestandsprojekte zählt: Was reduziert Wartungsaufwand, was schließt Sicherheitslücken, und was ist ehrlicherweise nur für Neuentwicklung interessant.
Welche PHP 8.4 Features den Wartungsaufwand direkt senken
Property Hooks: getter und setter ohne Boilerplate
Property Hooks sind die auffälligste Neuerung. Sie erlauben es, Logik direkt an eine Eigenschaft zu binden, ohne separate getX()- und setX()-Methoden zu schreiben. In gewachsenen Klassen finden Sie oft Dutzende trivialer Getter, die nur ein Feld zurückgeben, und Setter, die nebenbei validieren.
class Kunde {
public string $email {
set(string $value) {
if (!str_contains($value, '@')) {
throw new InvalidArgumentException('Ungültige E-Mail');
}
$this->email = strtolower($value);
}
}
}
Der praktische Wert für Bestandscode: Sie können ein öffentliches Feld nachträglich mit Validierung versehen, ohne den Zugriff im restlichen Code auf Methodenaufrufe umzustellen. Ein $kunde->email = '...' an hundert Stellen bleibt unverändert gültig. Das ist selten bei Sprach-Features — meist zwingen sie zu Umbauten. Hier ist es umgekehrt.
Asymmetrische Sichtbarkeit: öffentlich lesen, privat schreiben
Bisher galt eine Sichtbarkeit für Lesen und Schreiben gleichermaßen. Wollten Sie ein Feld nach außen lesbar, aber nur intern beschreibbar machen, brauchten Sie einen Getter plus ein privates Feld. Mit asymmetrischer Sichtbarkeit schreiben Sie das direkt:
class Bestellung {
public private(set) string $status = 'offen';
}
Von außen ist $bestellung->status lesbar, aber nur Methoden der Klasse dürfen ihn ändern. Für Legacy-Modelle, in denen der Zustand versehentlich von überall verändert wurde, ist das ein sauberer Weg, Invarianten Schritt für Schritt zu erzwingen — ohne die Lesezugriffe zu brechen.
PHP 8.4 Features für Sicherheit und Datenqualität
Die neue HTML5-fähige DOM-API
Wer in Bestandsprojekten HTML parst — für Import, Scraping oder Template-Nachbearbeitung — kennt das Elend mit DOMDocument: Es basiert auf einem HTML4-Parser und zerlegt modernes HTML5 regelmäßig falsch. PHP 8.4 bringt mit Dom\HTMLDocument einen standardkonformen HTML5-Parser.
$dom = \Dom\HTMLDocument::createFromString($html);
$links = $dom->querySelectorAll('a.extern');
Neben dem korrekten Parsing bekommen Sie querySelector und querySelectorAll nativ. In der Praxis ersetzt das oft fragile XPath-Konstrukte oder externe Bibliotheken. Wenn Ihr Altsystem HTML entgegennimmt und weiterverarbeitet, ist das eines der wenigen Features, das direkt eine Fehlerklasse eliminiert.
Das #[\Deprecated]-Attribut: Migration planbar machen
Für die schrittweise Modernisierung ist das neue #[\Deprecated]-Attribut unterschätzt wertvoll. Sie markieren eine alte Methode als veraltet, und PHP löst bei jedem Aufruf eine Deprecation-Warnung aus.
class ZahlungsService {
#[\Deprecated(message: 'Nutzen Sie processPayment()', since: '2.5')]
public function zahle(): void { /* ... */ }
}
Das erlaubt eine ehrliche Übergangsphase: Der alte Weg funktioniert weiter, aber jeder Aufruf wird sichtbar. In Kombination mit einem Log-Handler sehen Sie über Wochen, welche Aufrufer noch existieren, bevor Sie etwas löschen. Genau so migriert man Bestandscode risikoarm, statt mit dem großen Schnitt.
Kleinere Verbesserungen mit spürbarem Alltagsnutzen
- Array-Funktionen
array_find,array_any,array_all: Ersetzen die immergleichenforeach-Schleifen mit Flag-Variablen. Weniger Zeilen, klarere Absicht. newohne Klammern:new Service()->run()statt(new Service())->run(). Kosmetik, aber räumt in verschachteltem Code auf.- Lazy Objects: Objekte, die erst bei erstem Zugriff initialisiert werden. Relevant für Frameworks und ORMs; Symfony und Doctrine nutzen das intern, sodass Sie den Vorteil oft ohne eigenen Code bekommen.
Der wichtigste Grund, überhaupt auf 8.4 zu gehen
Der ehrlichste Grund für ein Update auf PHP 8.4 sind selten die neuen Features — es ist der Support. Ältere Versionen fallen aus dem Sicherheits-Support, und jede nicht mehr gepatchte PHP-Version ist ein wachsendes Risiko in Ihrem Stack. Der Sprung auf 8.4 kauft Ihnen Zeit im offiziellen Support-Fenster, und die Features sind das Sahnehäubchen, mit dem Sie die ohnehin nötige Migration produktiver gestalten.
Ein wichtiger Hinweis zur Migration selbst: PHP 8.4 verschärft einige Deprecations, etwa bei implizit nullbaren Parametertypen (function f(Foo $x = null) muss zu ?Foo $x = null werden). Das trifft ältere Codebasen häufig. Solche Warnungen sind aber genau die Art Arbeit, die sich automatisiert erledigen lässt, bevor sie in einer künftigen Version zu harten Fehlern werden.
Was das für Ihr Bestandsprojekt bedeutet
Wie steige ich sinnvoll auf PHP 8.4 um? Fahren Sie Ihre Tests unter 8.4, sammeln Sie zuerst alle Deprecation-Meldungen ein, und beheben Sie diese, bevor Sie neue Features einsetzen. Erst danach lohnt es sich, Property Hooks oder die neue DOM-API gezielt dort einzuführen, wo sie echten Schmerz beseitigen.
Mein Praxis-Tipp: Führen Sie kein einziges neues Feature ein, nur weil es neu ist. Nehmen Sie sich die zwei oder drei Stellen vor, an denen Ihr Code heute regelmäßig bricht oder schwer wartbar ist — HTML-Parsing, überall veränderbarer Zustand, ein Wust trivialer Getter — und lösen Sie gezielt diese. Eine Neuentwicklung ist fast immer die teuerste und riskanteste Option; ein gezieltes Update ist der ruhige, günstige Weg. Wenn Sie bei genau dieser Priorisierung und der Migration selbst eine zweite Meinung brauchen, unterstützt LegacyWerk bei solchen Modernisierungen ohne den großen Neubau.