PHP 8.4 neu in 2025: Was Legacy-PHP-Projekte konkret prüfen sollten
PHP 8.4 neu? Das war im November 2024. Seitdem ist die Version in fast jedem Hosting-Panel wählbar. Viele Projekte laufen trotzdem noch auf 8.1 oder 8.2. Und einige auf 7.4. Wer jetzt umstellen will, findet in 8.4 zwei Arten von Änderungen. Die einen sind neue Sprachfunktionen. Die anderen sind Deprecations, also Warnungen für Code, der in einer späteren Version nicht mehr läuft.
Für ein Projekt von 2014 ist die zweite Gruppe die wichtigere. Dieser Artikel geht beide durch. Am Ende steht eine Prüfliste, die Sie an Ihren Entwickler weitergeben können.
Warum PHP 8.4 gerade für ältere Projekte zählt
Der Support-Kalender hat sich mit 8.4 geändert. Jede Version bekommt jetzt zwei Jahre aktive Pflege und danach zwei Jahre Sicherheits-Updates. Für 8.4 heißt das: Bugfixes bis Ende 2026, Sicherheits-Patches bis Ende 2028. Details zum Modell finden Sie im Beitrag über Long-Term Support.
PHP 8.1 bekommt seit Anfang 2026 keine Updates mehr. PHP 8.2 fällt Ende 2026 aus dem Support. Wer heute auf 8.2 sitzt, hat also noch wenige Monate. Ein Sprung auf 8.4 kauft vier Jahre Ruhe. Welche Version aktuell sinnvoll ist, erklärt der Artikel aktuelle PHP-Version.
Was ist in PHP 8.4 neu?
Die neuen Funktionen betreffen fast nur Code, den Sie neu schreiben. Alter Code läuft damit nicht schlechter. Trotzdem lohnt ein Blick, weil einige davon typische Legacy-Muster ablösen.
Property Hooks
Bisher brauchten Klassen für jede Eigenschaft ein getName() und ein setName(). Mit Property Hooks hängt die Logik direkt an der Eigenschaft. Ein Beispiel:
class Kunde
{
public string $email {
set(string $wert) {
$this->email = strtolower(trim($wert));
}
}
}
Für Legacy-Projekte ist das vor allem beim Aufräumen interessant. Hunderte Getter und Setter lassen sich Schritt für Schritt ersetzen. Pflicht ist das nicht.
Asymmetrische Sichtbarkeit
Eine Eigenschaft darf jetzt öffentlich lesbar, aber nur intern schreibbar sein: public private(set) int $id. Das spart Getter, die nur einen Wert zurückgeben. In alten Datenmodellen mit vielen öffentlichen Feldern hilft das, Schreibzugriffe von außen zu unterbinden, ohne alles umzubauen.
Neue Array-Funktionen
array_find(), array_find_key(), array_any() und array_all() sind neu. Bisher schrieb man dafür eine foreach-Schleife mit break. Solche Schleifen gibt es in alten Projekten zu Hunderten. Sie funktionieren weiter. Wer sie anfasst, kann sie jetzt kürzer schreiben.
Neue DOM-API und weitere Kleinigkeiten
Die Klasse Dom\HTMLDocument versteht HTML5. Das alte DOMDocument kam mit modernem Markup oft nicht zurecht und warf Warnungen. Wer HTML aus Fremdquellen parst, etwa für Scraper oder Newsletter-Vorschauen, bekommt hier ein sauberes Werkzeug.
Dazu kommen mb_trim(), ein new ohne Klammern beim Verketten von Methodenaufrufen (new Foo()->bar()) und Lazy Objects. Letztere erzeugen ein Objekt erst, wenn es wirklich benutzt wird. Für Frameworks relevant, für Ihren Anwendungscode meist nicht.
Welche Deprecations treffen Legacy-Projekte?
Hier wird es konkret. Eine Deprecation ist noch kein Fehler. Der Code läuft, PHP schreibt aber eine Warnung ins Log. In PHP 9 wird daraus ein Abbruch. Wer die Warnungen jetzt ignoriert, schiebt das Problem um zwei bis drei Jahre.
Implizit nullable Parameter
Das ist der häufigste Treffer in altem Code. Diese Schreibweise war lange üblich:
function speichern(Kunde $kunde = null) { ... }
Ab 8.4 verlangt PHP das explizite Fragezeichen: ?Kunde $kunde = null. In einem Projekt mit 50.000 Zeilen finden sich davon schnell 200 Stellen. Die Korrektur ist mechanisch, aber sie muss gemacht werden. Tools wie Rector erledigen das automatisch.
Ausgelagerte Erweiterungen
Vier Erweiterungen sind nicht mehr Teil von PHP: imap, oci8, pdo_oci und pspell. Sie liegen jetzt im PECL-Verzeichnis und müssen separat installiert werden. Das klingt harmlos, ist aber ein klassischer Stolperstein. Der alte Newsletter-Import per IMAP läuft auf dem Testserver, weil dort jemand die Erweiterung nachinstalliert hat. Auf dem neuen Produktivserver fehlt sie. Prüfen Sie php -m auf beiden Systemen.
Alte Konstanten und Klassennamen
Die Konstante E_STRICT ist veraltet. Sie taucht in vielen alten error_reporting()-Aufrufen auf. Ein Unterstrich als Klassenname (class _ {}) ist ebenfalls veraltet. Selten, aber in generiertem Code aus den 2000ern durchaus zu finden.
Datenbank und Session
Bei mysqli sind mysqli_ping(), mysqli_kill() und mysqli_refresh() veraltet. Der Ping-Aufruf steckt oft in Verbindungsklassen, die lange Prozesse am Leben halten sollen. Bei Sessions sind die Einstellungen session.sid_length und session.sid_bits_per_character veraltet. Wer diese Werte in der php.ini oder per ini_set() setzt, bekommt Warnungen.
Rundung und Randfälle
round() verhält sich bei bestimmten Fließkommazahlen minimal anders als früher. Wer Preise mit round() berechnet und Cent-genau abgleicht, sollte die Tests laufen lassen. Auch xml_set_object() und die alten Callback-Varianten der XML-Parser-Funktionen sind veraltet. Das sind Randfälle, aber genau die Randfälle, die nachts um drei ausfallen.
Die Prüfliste für Ihr Projekt
So gehen wir vor, wenn ein Kunde mit einem älteren Projekt auf PHP 8.4 will.
Zuerst läuft die Anwendung mit error_reporting(E_ALL) auf einem Testsystem mit 8.4. Alle Deprecations landen im Log. Das dauert einen Tag und zeigt, wie groß das Thema wirklich ist.
Dann prüfen wir die Erweiterungen. php -m auf dem alten und dem neuen Server, Ausgabe vergleichen. Fehlt imap oder oci8, muss das ins Deployment.
Als Drittes kommen die Abhängigkeiten. Composer-Pakete, die seit 2019 kein Update gesehen haben, brechen häufiger als der eigene Code. composer outdated zeigt die Liste. Manchmal hilft nur ein Fork oder ein Ersatz.
Danach die mechanischen Korrekturen: nullable Parameter, E_STRICT, mysqli-Aufrufe. Dafür nutzen wir Rector mit dem Regelsatz für 8.4. Das Ergebnis lesen wir trotzdem Zeile für Zeile.
Zum Schluss ein kompletter Testlauf. Gibt es keine automatisierten Tests, klicken wir die Kernprozesse durch: Login, Bestellung, Export, Rechnung. Wie sich das in eine größere Modernisierung einbetten lässt, beschreibt der Beitrag zur PHP-Modernisierung.
Was ein Projekt auf PHP 7 davon hat
Wenn Ihre Anwendung noch auf 7.4 läuft, kommen die Punkte aus diesem Artikel obendrauf. Die großen Brüche liegen zwischen 7 und 8.0: strengere Typprüfung, geänderte String-zu-Zahl-Vergleiche, entfernte Funktionen. Was dort ansteht, beschreibt der Artikel zum PHP 7 End of Life. Der Sprung direkt auf 8.4 ist trotzdem sinnvoll. Zwei Migrationen hintereinander kosten mehr als eine gründliche.
Über die Jahre hat sich in solchen Projekten einiges angesammelt. Das ist kein Vorwurf. Code von 2014 wurde für das PHP von 2014 geschrieben, und er hat zwölf Jahre gearbeitet. Jetzt braucht er eine Anpassung, damit er weitere Jahre arbeitet.
Fazit: Deprecations zuerst, Features später
Die neuen Sprachfunktionen in PHP 8.4 sind nett, aber für Bestandsprojekte optional. Die Deprecations dagegen müssen Sie abarbeiten. Implizit nullable Parameter, ausgelagerte Erweiterungen und veraltete mysqli-Aufrufe sind die drei Stellen, an denen alte Projekte am häufigsten hängen bleiben.
Wer die Warnungen jetzt abarbeitet, hat bis Ende 2028 Ruhe. Wer wartet, hat 2027 dasselbe Problem mit engerem Zeitplan.
Sie wissen nicht, wie viele Deprecations in Ihrem Projekt stecken? Wir prüfen das auf einem Testsystem und sagen Ihnen, was der Umstieg kostet. Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Alternativ können Sie direkt ein PHP-Upgrade beauftragen.
