The Php Times

PHP 8.6's deprecation RFCs have passed. While no code breaks in the new version, deprecated functions generate warnings that easily slip past unnoticed—especially when vendor packages issue those warnings in hot code paths.

In projects with notice-level logging enabled (common in Laravel setups), each deprecation call floods logs, inflating disk usage and ingestion costs. Teams often diagnose this as a logging infrastructure problem rather than recognizing it as a code modernization issue, delaying the actual fix.

The core friction point is vendor packages. Your own codebase can be updated quickly, and tools like Rector can automate much of that work. Vendor dependencies lacking PHP 8.6-ready releases continue emitting warnings until the upstream maintainer releases a fix—a timeline outside your control.

A practical approach: enable E_DEPRECATED as an error in CI before shipping. This catches deprecations during testing rather than after deployment into production logs. A minimal implementation converts deprecation warnings to exceptions:

error_reporting(E_ALL); set_error_handler(function ($errno, $errstr, $errfile, $errline) { if ($errno === E_DEPRECATED || $errno === E_USER_DEPRECATED) { throw new \ErrorException($errstr, 0, $errno, $errfile, $errline); } return false; });

This turns deprecation warnings into hard test failures, preventing them from silently bloating production logs. The debate in the community remains: implement a strict CI gate for deprecations, or accept and manage the noise until resources allow remediation.