Error messages showing up to users

Could it be that you were just seeing cached pages? If the errors don’t reappear after clearing the cache, that might be the simplest explanation.

You can certainly use define('WP_DEBUG_DISPLAY', false); without an if statement if you prefer. The if is just a precaution for situations where the user might already have other custom code in the file that also defines WP_DEBUG_DISPLAY. Trying to define it a second time would trigger an error.

Thanks for your quick reply and explanation.

I agree with you that the page with error is being cached. But this page hasn’t changed so why did the version with errors cached in the first place?

If errors are never shown to users, the cached pages should never have errors logs, correct ?

Assuming that errors are never shown to users, yes, cached pages should not show errors.

Was there any point when WP_DEBUG was already enabled but the rest of the code wasn’t added yet? That could explain why errors showed up.

No. Both codes were inserted in the same time.

I have even emptied the cache, the issue was resolved and the page was cached again with errors.

To confirm, are you saying that the errors have reappeared now, after error display was already turned off? So you had errors, then no errors after reloading the cache, and now errors again after emptying the cache?

I suppose some other code may be setting display_errors to on, or something in the server configuration prevents it from being turned off properly. This could be hard to debug. It’s also probably not related to Error Log Monitor: the wp-config.php constants are part of WordPress core, and the settings changed via ini_set are part of PHP.

Thanks for your response.

You understood the situation correctly.

I will keep looking for an explanation

In the “if” statement, we are only checking if WP_DEBUG_DISPLAY is defined should we check if it’s set to true as well, so we can set it to false?

I’m not an php programmer but something like

if ( !defined(‘WP_DEBUG_DISPLAY’) || (WP_DEBUG_DISPLAY == true) ) {
define(‘WP_DEBUG_DISPLAY’, false);
}

does it make sense to you?

In this context, WP_DEBUG_DISPLAY is a PHP constant. You could modify the code to check if it is both defined and set to true, but you couldn’t then change it to false. Once a constant has been defined, its value can’t be changed.

In practice, it would probably be enough to search the rest of wp-config.php for other instances of WP_DEBUG_DISPLAY and see if it’s set to true. After the code that sets it to false is executed, other code can’t redefine it to true, so it’s not necessary to look beyond wp-config.php.

On the other hand, display_errors is not a constant – it’s a PHP configuration option. By default, any PHP file can change it. So if code in wp-config.php turns it off, other code somewhere else (e.g. in a plugin) could turn it on again.

However, some hosting providers prevent PHP scripts from changing certain PHP options. This means that you wouldn’t be able to change them in wp-config.php and plugins wouldn’t be able to change them either (the code that tries to change them would still run, but it wouldn’t have any effect). I don’t know an easy way to check if something like that is going on; you could try asking the host about it.

Thanks a lot for all these information. I really appreciate it !

There is no other mention to WP_DEBUG_DISPLAY in wp-config.php, but when I try to remove the if statement, I get a message saying that the constant was already defined, but I don’t know where.

I ran a grep -sr "WP_DEBUG_DISPLAY" --include *.php . and got the following :

https://drive.google.com/file/d/1eX_u9EL2sQYDOlY9kfccGFcYbXLh6ahC/view?usp=sharing

Isn’t it strange? I’ll contact my host as you suggested.

That sounds very unusual. I don’t see anything in that grep output that could set WP_DEBUG_DISPLAY to true before the code in wp-config.php is executed (/wp-includes/default-constants.php runs later, after wp-config.php).

Technically, there are ways to run PHP code before any of the WordPress files are loaded, like the auto_prepend_file option. But it seems unlikely that anyone would do this to define the WP_DEBUG_DISPLAY constant.

I wrote to my host and they got back to me.

So I had put the code at the end of wp-config.php. They told me that it has to be placed a little bit earlier in the file.

They moved the following part of the code after my code:

/* That's all, stop editing! Happy blogging. */
/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');
/* Fixes "Add media button not working", see https://www.carnfieldwebdesign.co.uk/blog/wordpress-fix-add-media-button-not-working/ */
define('CONCATENATE_SCRIPTS', false );
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

In wp-settings, there is a call to wp_initial_constants that is defined in wp-includes/default-constants.php and has the following code:

// Add define( 'WP_DEBUG_DISPLAY', null ); to wp-config.php to use the globally configured setting
// for 'display_errors' and not force errors to be displayed. Use false to force 'display_errors' off.
if ( ! defined( 'WP_DEBUG_DISPLAY' ) ) {
define( 'WP_DEBUG_DISPLAY', true );
}

As far as I remember, the plugin instructed me to put the code at the end. Is this wp-settings and default-constants specific to my host ?

Thanks a lot for your time and insights!

• This reply was modified 1 year, 7 months ago by duduklein.

The instructions in the plugin say “please add this code to wp-config.php”; they don’t specify where exactly to add it. I guess I’m too familiar with how wp-config.php works – it just didn’t occur to me to mention that any custom come should go above the line that says /* That's all, stop editing! Happy blogging. */. Having the code at end of the file does explain why it couldn’t set the WP_DEBUG_DISPLAY constant.

In any case, it’s good to hear that it has been solved now.

I’m no WP or PHP expert, but in my case, it seems that adding the code to the end of the file was not effective, because the constant WP_DEBUG_DISPLAY was defined in the function wp_initial_constants that was called in the wp-settings file.

As you explained to me that this is a constant and can’t be redefined, once it was defined in that file (and it was set to true), I couldn’t redefine it to false. This seems to be the explanation to me.

Yes, that is broadly correct.