WP_DEBUG is not set, but I’m still getting warnings

1 Views

If WP_DEBUG is not set, as I understand it, you should never ever see warnings. But on some sites on some servers, I’m still seeing a few. Not all the warnings that would be displayed if WP_DEBUG was set, but a select few.

I’ve tried changing the error level in php.ini, but that seems to have no effect on whether warnings appear or not, but they do appear in differing amounts on different servers (i.e. no warnings on development, one warning on staging, and a few more warnings on production).

Post Views: 1

Related posts

Leave a Reply

6 comments

  1. WP_DEBUG has no impact on PHP error output. In addition to error_reporting setting, set display_errors=0 in your php.ini file. It’s enabled by default for development. But you’ll want it off on production servers.

  2. Replace 

    define('WP_DEBUG', false);

    with this:

    ini_set('log_errors','On');

ini_set('display_errors','Off');

ini_set('error_reporting', E_ALL );

define('WP_DEBUG', false);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);

  3. It is also possible, that this line is already set to false. In that case, you’ll see the following code:

    define('WP_DEBUG', false);

    In either case, you need to replace this line with the following code:

    ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

    Don’t forget to save your changes and upload your wp-config.php file back to the server.

  4. For WordPress environments, there is usually no reason to use ini_set because that is what the defined constants provided by WordPress Core are already achieving. The way that PHP works is that certain settings can be overridden within your CMS (WordPress), within individual scripts, and even on a per-user or per-directory basis (much to the frustration of web hosts and agencies).

    To disable errors from displaying on-page in WordPress, the only setting you really need is:

    define('WP_DEBUG', false);

    …because when WP_DEBUG is disabled, the sub-options are then inactive:

    define('WP_DEBUG_DISPLAY', false);
define('WP_DEBUG_LOG', false);

    Keep in mind that the confusing WP_DEBUG_LOG option only refers to the creation of debug.log within the directory wp-content and does not effect other logging settings, etc.

    Again, the settings in WordPress can override default PHP settings, so your PHP settings don’t matter as much as having correct settings in your wp-config.php file, which loads before other WP components.

    That said, it is a good idea to implement default settings like below in production:

    error_reporting = E_ERROR | E_WARNING | E_PARSE
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/www/logs/error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
report_memleaks = On
xmlrpc_errors = 0
html_errors = Off

    For a complete example, refer to our SlickStack php.ini file optimized for Nginx and PHP-FPM.

    In one case, after hours of research, we realized a plugin (or theme) was overriding the various error handling settings previously set in php.ini and wp-config.php. The only way to prevent this is to remove the WordPress plugin or theme that is trying to “hack” your PHP settings, or tell them to remove it because that is very bad practice for extensions to be overriding the debug options of your CMS.

    In SlickStack, we created a Bash script that “flags” any ini_set and error_reporting lines from PHP files in the /themes/ and /plugins/ directories by highlighting such instances using a MU Plugin (PHP script) that displays a list of such “hacks” in the WP Admin Dashboard.

  6. None of the solutions above have worked for me.

    For me, the solution was to add a php file into the mu-plugins folder. Just create a php file and add the following line.

    error_reporting(E_ALL & ~( E_NOTICE ));

    After that, upload it into the mu-plugins folder (if the folder doesn’t exist, create it into the wp-content folder).