E_DEPRECATED noise in production error_log

Recommended Error Reporting Configuration

To isolate fatal errors and warnings while suppressing deprecation noise in a production environment, use a bitmask that excludes E_DEPRECATED and E_USER_DEPRECATED. This ensures that critical runtime failures are captured without bloating logs during version transitions.

In your php.ini, set the following:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED
display_errors = Off
log_errors = On

Explanation of the Bitmask

The E_ALL & ~E_DEPRECATED syntax tells PHP to report all errors except those marked as deprecated. In PHP 8.x, deprecations are non-fatal and do not interrupt execution, but they are triggered frequently by legacy libraries during major version jumps. By removing them from the production bitmask, you reduce disk I/O and prevent critical E_ERROR entries from being buried in noise.

Throttling Deprecations via Custom Handlers

A custom set_error_handler can effectively throttle repeated messages. Because E_DEPRECATED often triggers on every single call to a specific legacy function, logging every instance is redundant. You can implement a static cache to track unique error signatures.

Implementation Strategy:

• Create a handler that intercepts E_DEPRECATED.
• Generate a hash of the error message and file path.
• Store the hash in a static array or a fast cache (like APCu).
• Log the error only if the hash has not been seen during the current request or within a specific time window.

Note that while this reduces log volume, it adds a small amount of overhead to every deprecated call. For high-traffic environments, the php.ini bitmask is the more performant solution.

Verification Steps

To verify your current configuration without restarting the server, run the following CLI command:

php -r "var_dump(error_reporting());"

To test the suppression, trigger a known deprecated function in a staging environment and tail the log: tail -f /var/log/php_errors.log.

Diagnostic Detail Needed: Are these deprecations originating from your own application code or from third-party vendor packages (/vendor)? If they are third-party, a custom handler is preferred over a global bitmask to ensure your own code's deprecations remain visible in development.