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
  • I had the exact same issue, it was WARNINGS from GravityForms in my case the warning output was - Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /plugins/gravityforms/common.php - Logic Digger's answer below worked copy/paste for me to fix this first try, thanks. – OG Sean Feb 14 at 19:12

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.

| improve this answer | |
  • 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. – user202 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. – user202 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);
| improve this answer | |
  • 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.

| improve this answer | |
  • 1
    Thanks this worked to hide warnings on the front end for me. WP_DEBUG was already set to false. – OG Sean Feb 14 at 19:12

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.

| improve this answer | |

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.

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

Your Answer

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