The Php Times

Die Massenabstimmung zu Deprecations für PHP 8.6 ist abgeschlossen: 35 separate RFCs standen zur Wahl, die meisten wurden angenommen. Deprecated Funktionen funktionieren in 8.6 weiterhin — sie geben lediglich Warnungen aus. Das klingt harmlos, hat aber zwei praktische Folgen.

Erstens wird das Logvolumen zum Kostenfaktor. In einem produktiven Laravel-Projekt mit aktiviertem Notice-Logging erzeugt eine deprecated Funktion in einem Hot Path, der tausende Male pro Minute aufgerufen wird, einen kontinuierlichen, sich aufsummierenden Log-Strom: Festplattenplatz, Ingestion in Systeme wie Loki oder ELK und letztlich Geld. Das Symptom zeigt sich als „gestiegene Logging-Kosten" und landet oft beim falschen Team, Wochen nachdem der verursachende Code ausgeliefert wurde.

Zweitens liegen viele Deprecations außerhalb der eigenen Kontrolle. Eigener Code lässt sich schnell bereinigen — Werkzeuge wie Rector automatisieren einen Großteil davon —, aber Vendor-Pakete ohne 8.6-kompatibles Release machen so lange Lärm, bis der Upstream-Maintainer einen Fix liefert. Bei einem dependency-lastigen Stack können das Wochen unvermeidlichen Log-Rauschens sein.

Eiligkeit ist nicht geboten: PHP 8.5 wird noch Jahre unterstützt, und Deprecations werden erst dann brisant, wenn sie irgendwann zu Removals werden. Sobald das Upgrade aber ansteht, empfiehlt der Autor, Deprecations als CI-Thema zu behandeln statt als Produktions-Logging-Problem: zuerst die PHP-Version in CI hochziehen, E_DEPRECATED und E_USER_DEPRECATED per Error-Handler (der eine ErrorException wirft) den Build fehlschlagen lassen, eigenen Code fixen, Vendor-Pakete aktualisieren oder Upstream-Issues verfolgen — und erst danach den Versionssprung in die Produktion ausrollen.

Bei hartnäckigen Vendor-Deprecations lohnt sich laut Artikel die Prüfung, ob bereits eine neuere Paketversion 8.6-tauglich ist, ob der deprecated Aufruf im eigenen Nutzungspfad überhaupt erreichbar ist oder entfernt werden kann, und — sparsam eingesetzt — ob eine gezielte Unterdrückung der Warnung mit @ am Callsite sinnvoll ist, statt das CI-Gate komplett abzuschalten. Der Gewinn: ein Fünf-Minuten-PR-Fix statt der Suche nach der Ursache einer explodierten Observability-Rechnung drei Wochen später.