WordPress debug log is very useful to developers as it allows to see many issues our code (or third-party code) may be causing. This is often the first point of call when there is a problem on a website — checking the log.
When working with a site that has a lot of plugins, there are times where the log can become difficult to parse visually. Deprecation notices are one thing that occasionally get in the way on a few projects I’ve worked on and when the log is full of deprecation notices, it’s hard to see if/when my code is causing any warnings, notices, or errors.
WordPress uses a collection of functions for deprecating code. These are great because they allow developers to indicate (via the debug.log
) that a particular piece of code is deprecated and also specify what to use instead. Within each of these functions there is a filter we can use to prevent the call to PHP’s trigger_error()
function which will stop the warning from appearing in our debug.log
file. By implementing the snippet below, you’ll be able to stop all deprecation notices passing through WordPress’ core deprecation functions from clogging up the log file.
Be mindful that it is always better to fix any code resulting in a warning or updating and outdated plugins that may be causing it. The following snippet is intended to be a temporary fix to facilitate development.
If you drop this snippet into an MU plugin, you’ll ensure it runs nice and early and have the best chance of stopping as many deprecation notices as possible.
A note on WooCommerce’s deprecation notices
Unfortunately, the above strategy won’t work for anything deprecated in WooCommerce when a request is either an AJAX request or a WordPress REST API call. This is because WooCommerce uses its own deprecation functions which contain a condition checking for AJAX and REST API calls. If the current request matches either of these conditions, WooCommerce calls trigger_error()
directly and does not provide the same filters for disabling the logged error.