Expand WP_DEBUG_LOG and make WP_DEBUG_DISPLAY work as expected

[nacin]

WP_DEBUG_LOG

WP_DEBUG_LOG currently creates wp-content/error.log. We should expand this to allow a path.

To do this, if WP_DEBUG_LOG is !== true, != 1, != 'true', (anything else?) and 0 === validate_file(), we should treat it as a path.

WP_DEBUG_DISPLAY

Setting WP_DEBUG_DISPLAY to false does not set display_errors to false. Instead, it prevents display_errors from being set to on. This forces a call to ini_set to turn off display_errors, assuming your php.ini is set to On, as expected for a development environment configuration.

Instead, setting WP_DEBUG_DISPLAY to false should set display_errors to false. I've been thinking about this for months now, and the only situation I can come up with that this would be a compatibility issue would be when you deliberately have a production php.ini on production and a development php.ini in development. In this situation, WP_DEBUG_DISPLAY = false would screw up your development environment only -- the only breakage would be showing less errors, rather than more.

WP_DEBUG_DISPLAY === null can remain a passthrough.

Patch forthcoming.

[nacin]

In [18545]:

Force display_errors to off when WP_DEBUG_DISPLAY == false. Technically a backwards incompatible change - if you want the passthrough to php.ini (which false used to provide) then use WP_DEBUG_DISPLAY === null. see #18391.

[duck_]

Replying to edwardw:

The patch has only been partially applied so far. We need to decide whether or not the second part will applied before closing.

[ocean90]

We need to decide whether or not the second part will applied before closing.

Second part is WP_DEBUG_LOG?

[nacin]

Punting the WP_DEBUG_LOG path support. Feels like something isn't quite right about the patch.

[chriscct7]

Closing as wontfix on the WP_DEBUG_LOG path support part. Complete lack of interest on the feature on the ticket over the last 4 years. Feel free to reopen when more interest re-emerges (particularly if there's a patch)

[SergeyBiryukov]

#34441 was marked as a duplicate.

[sebastian.pisula]

I add patch for 4.5-beta1-36775

[dd32]

#38735 was marked as a duplicate.

[ethitter]

Refreshed the patch as I'm in a situation where WordPress runs in a read-only environment, and I'd like to enforce WP_DEBUG_DISPLAY as false while also ensuring logs can be gathered via WP_DEBUG_LOG to a temporary directory.

[jabranr]

Came here with similar dilemma and found a patch already in this ticket. Using WP_DEBUG_LOG as string path to a custom location is best solution IMO. +1 for this to be available during next release as it would make development lot smoother. My development case is based on using WP docker image.

[SergeyBiryukov]

validate_file() cannot be used here, as wp_debug_mode() is called before wp-includes/functions.php is included. We could duplicate its checks here, but I wonder how useful they are in this context. If someone has access to define WP_DEBUG_LOG, they could as well set error_log directly.

is_writeable() check cannot be used either, as it requires the file to exist, but it may not be created yet.

18391.3.diff​ is my take on the patch.

[jabranr]

IMHO, I don't see much of a point in checking if a developer's given file location exists or not. If developer is capable enough to specify a custom file location then file_write error should easily be understandable in case of a wrong file location. My take would be one of followings as already given in some of above patches:

WP_DEBUG_LOG = true
WP_DEBUG_LOG = 1
WP_DEBUG_LOG = /tmp/wordpress.log

My case is using docker image of WP where I can simple define this as part of the environment variables which would save me the hassle of sneaking in a line with "ini_set" to otherwise enable a custom location for logs. Example docker-compose:

...

services:
  wordpress:
    image: wordpress:latest
    environment:
      - WP_DEBUG=1
      - WP_DEBUG_LOG=/tmp/wordpress.log
...

PS could someone please post a link to the guidance on how to contribute to WP?

[acobster]

I agree with @jabranr, PHP's native file system errors seem perfectly fine to me in the case of a bad path.

Here's that link btw:

​https://codex.wordpress.org/Contributing_to_WordPress

[jabranr]

Replying to acobster:

Thank you!

I agree with @jabranr, PHP's native file system errors seem perfectly fine to me in the case of a bad path.

Here's that link btw:

​https://codex.wordpress.org/Contributing_to_WordPress

[pento]

In 44453:

Bootstrap: Allow WP_DEBUG_LOG to override the debug.log location.

Setting WP_DEBUG_LOG to a file path will now cause the debug log to be written to that file, rather than the default WP_CONTENT_DIR/debug.log.

Props SergeyBiryukov, ethitter, sebastian.pisula, nacin.
Fixes #18391.

[desrosj]

This was detailed in a dev note: ​https://make.wordpress.org/core/2019/01/23/miscellaneous-developer-focused-changes-in-5-1/