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).

  • Are these definitely warnings, or fatal errors? – TheDeadMedic Jun 10 '11 at 15:52

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.

  • To paraphrase wp-includes/load.php: if(WP_DEBUG)error_reporting(E_ALL). But it does seem like several plugins are fiddling with error_reporting and display_errors when they probably shouldn't be. – tomdxw Jun 13 '11 at 13:24
  • 1
    Ah - you're right, display_errors was set to On in my php.ini. I just assumed WP_DEBUG took care of all the errors. Thank you. – tomdxw Jun 13 '11 at 13:32


define('WP_DEBUG', false);

with this:



ini_set('error_reporting', E_ALL );

define('WP_DEBUG', false);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);
  • 4
    Please add an explanation to your answer. – fuxia Oct 18 '15 at 19:09
  • Probably errors on screen are off, but you can see them in your server in the error log – user2060451 Oct 28 '16 at 18:00

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('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.


Try to disable/suppress all error warnings/notices in your wp-config.php (on top). Anyway: Errors are nothing bad. They give you a chance to fix your code.

  • I think it was other people's plugins fiddling with error_reporting that caused this. – tomdxw Jun 13 '11 at 13:41

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 manually removes any ini_set and error_reporting lines from PHP files in the /themes/ and /plugins/ directories :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.