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.