Silence is Golden, Debugging is Silver

How to adjust PHP error reporting for WordPress Debugging

It’s important to be aware of any issues in your code when you develop for WordPress. But sometimes, too much information is just … too much. Here is an efficient way of choosing which notices are important to you and which are not.

When you develop plugins or themes for WordPress and use one of the latest versions of PHP (8.1 for production at the time of writing), you may find that there are a lot of deprecated notices logged to your site’s debug.log when you have debugging enabled. For your convenience, at the end of this post, you will find instructions on how to enable debugging for WordPress.

Those deprecated notices may come from the WordPress core and active plugins. This even happens when you use the latest WordPress development version, currently at 6.2-alpha. While this information is certainly important when you work on WordPress core, it’s a nuisance while developing plugins or themes. While your debug.log overflows with messages that are unrelated to your work, it distracts from actual issues that you might have with your own code.

In this post, you will learn how to minimize the messages that are logged and pinpoint issues that are relevant to your work.

PHP provides the error_reporting() function that allows to determine the error_reporting level at runtime. But when you try to use that in your site’s wp-config.php, it will not have the desired effect. Why not? WordPress predetermines a set of error levels in its wp-load.php right at the start. Then it comes to the site’s wp-config.php where you could be inclined to (but shouldn’t) determine your own set of error levels using the error_reporting() function. Then it continues processing the wp-settings.php where the wp_debug_mode() function is called, where WordPress will again determine the set of error levels depending on whether the WP_DEBUG constant is true or not.

So, putting the following line in your wp-config.php will NOT work:

error_reporting( E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED );

It won’t work like that, because WordPress will just override the error levels when it executes its wp_debug_mode() function.

Shut up!

Ok, but if the above doesn’t work, how do we get rid of those deprecated notices appropriately? The solution we will adopt is simple and efficient, based on WordPress’ Must Use Plugins. Don’t panic if you’re not familiar with those, it’s way simpler than you might think.

1. In your site’s wp-content directory, create the mu-plugins subdirectory.
2. Copy the file stfu.php from our stfu repository into the mu-plugins directory.

That’s it. If you now go to your site’s dashboard and look under Plugins > Installed Plugins, you will find the additional Must-Use section where this plugin appears. It’s already activated and working.

Note that you can’t just clone the repository into the mu-plugins directory, because WordPress only looks for PHP files right inside it.

As you can see, the file contains the same line which now has the intended effect when used within our Must Use Plugin:

error_reporting( E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED );

In the file, you will also find an alternative commented line as an example, where also PHP warnings and notices are suppressed.

If we just continue with the unaltered version of our file, then we will still get all notices, warnings and errors, but we won’t get any of those deprecated notices.

Say something!

In my case, I needed to get rid of all deprecated notices while working on updates of our plugins – the deprecated notices were coming from WP core and WooCommerce, because both contain code that raises those with the version of PHP I am using in development, PHP 8.1.9 at the moment.

So while these are interesting to see as WordPress’ core makes progress towards compatibility with the latest PHP, it’s annoying when you want to get things done and are only interested in issues with code that you work on yourself.

The line that is active in the stfu.php must-use plugin excludes deprecated notices.

The drawback to this is that if you use a deprecated thing in your own code … you won’t be made aware of it.

So let’s say, you work on a plugin in wp-content/plugins/myplugin …. and once you’re satisfied that it doesn’t raise any “normal” PHP errors, warnings or notices, you also want to see if it raises any PHP deprecated notices … then you’ll need to comment the line in stfu.php or remove the file from the mu-plugins folder and you could use the following to pay attention to anything related to your plugin:

$ tail -f debug.log | grep 'plugins/myplugin'

Execute that command while you’re in the wp-content directory in a terminal session.

Now you can test your plugin and see any deprecation issues particularly related to it. Now WordPress and other plugins will clutter your debug.log with “deprecated” notices, but you’ll filter these out and focus on lines that originate from within your own plugin.

So, now you know how to make your log more or less silent and focus on the interesting parts of it.

Let me know if this was useful, happy debugging!

How to enable debugging in WordPress

To enable debugging in WordPress, we need to modify the site’s wp-config.php which is located in the site’s root folder.

wp-config.php

...

// To enable debugging, we comment out the line that disables it,
// and we add a couple of constants that enable logging it to
// the site's wp-content/debug.log and avoid cluttering the
// output by disabling the display of logged messages:
//
// define('WP_DEBUG', false);
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

/* That's all, stop editing! Happy blogging. */

...

Photo credits: Photo by Nagara Oyodo on Unsplash