[wp-trac] [WordPress Trac] #34074: wp_debug false still showing errors
WordPress Trac
noreply at wordpress.org
Thu Dec 10 00:59:24 UTC 2015
#34074: wp_debug false still showing errors
--------------------------+------------------------------
Reporter: siebje | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version: 4.3.1
Severity: normal | Resolution:
Keywords: | Focuses:
--------------------------+------------------------------
Comment (by jrf):
Hi @siebje,
Congratulations on your first ticket and thank you for pointing this out.
I've had a look at this and from what I can see, this behaviour is by
design.
The `WP_DEBUG_DISPLAY` constant does ''not'' have ''any'' effect,
''unless'' `WP_DEBUG` is set to `true`.
See: https://codex.wordpress.org/Editing_wp-
config.php#Configure_Error_Logging for the documentation stating this:
> First off, remember that if WP_DEBUG is false, it and the other two
WordPress DEBUG constants do not do anything. The PHP directives, whatever
they are, will prevail.
In other words, if you do not set `WP_DEBUG` or set it to `false`, the
server PHP configuration for `display_errors` will be used as defined in
`php.ini`.
`display_errors` should always be off for production servers and is highly
recommended to be *on* for development servers.
If the PHP version upgrade you mention in your report was on a production
server, I would highly recommend that you switch to a more professional
web-host.
----
Having said that, I agree with you that a case could be made for changing
the behaviour, but considering that WP tries not to break backward
compatibility if it can be avoided at all, I kind of doubt it would get
in.
This was also discussed in ticket #11987 and decided against at that time.
Nevertheless, on the off-chance that someone would be willing to consider
it, I will upload a potential patch for this.
The patch presumes that if `WP_DEBUG` was not set by the admin or if it
was set to `false`, the displaying of errors should be turned off unless
the admin has explicitly set `WP_DEBUG_DISPLAY` to `null` to force WP to
follow the server settings.
The choice not to 'respect' `WP_DEBUG_DISPLAY` if set to `true` while
`WP_DEBUG` is `false` was made because the default setting for
`WP_DEBUG_DISPLAY` is `true` and changing the default seems even less
likely to find a kind ear.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/34074#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list