Make WordPress Core

Opened 13 years ago

Closed 5 years ago

Last modified 5 years ago

#18391 closed enhancement (fixed)

Expand WP_DEBUG_LOG and make WP_DEBUG_DISPLAY work as expected

Reported by: nacin's profile nacin Owned by: pento's profile pento
Milestone: 5.1 Priority: normal
Severity: normal Version:
Component: Bootstrap/Load Keywords: has-patch has-dev-note
Focuses: Cc:



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.


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.

Attachments (4)

18391.diff (2.4 KB) - added by nacin 13 years ago.
18391.patch (887 bytes) - added by sebastian.pisula 8 years ago.
18391.2.diff (962 bytes) - added by ethitter 7 years ago.
18391.3.diff (1.4 KB) - added by SergeyBiryukov 6 years ago.

Download all attachments as: .zip

Change History (27)

13 years ago

#1 @nacin
13 years ago

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.

#2 follow-up: @edwardw
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

#3 in reply to: ↑ 2 @duck_
13 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#4 @ocean90
13 years ago

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

Second part is WP_DEBUG_LOG?

#5 @nacin
13 years ago

  • Milestone changed from 3.3 to Future Release

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

#6 @nacin
10 years ago

  • Component changed from General to Bootstrap/Load

#7 @chriscct7
9 years ago

  • Keywords needs-patch added
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

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)

#8 @SergeyBiryukov
9 years ago

#34441 was marked as a duplicate.

#9 @sebastian.pisula
8 years ago

  • Keywords has-patch added; needs-patch removed
  • Resolution wontfix deleted
  • Status changed from closed to reopened

#10 @sebastian.pisula
8 years ago

I add patch for 4.5-beta1-36775

#11 @SergeyBiryukov
8 years ago

  • Milestone set to Awaiting Review

#12 @dd32
8 years ago

#38735 was marked as a duplicate.

7 years ago

#13 @ethitter
7 years ago

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.

#14 @jabranr
6 years ago

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.

#15 @SergeyBiryukov
6 years ago

  • Milestone changed from Awaiting Review to 5.0
  • Owner set to SergeyBiryukov
  • Status changed from reopened to reviewing

#16 @SergeyBiryukov
6 years ago

  • Keywords commit added

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.

#17 @jabranr
6 years ago

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 = /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:


    image: wordpress:latest
      - 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?

#18 follow-up: @acobster
6 years ago

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:

#19 in reply to: ↑ 18 @jabranr
6 years ago

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:

#20 @SergeyBiryukov
6 years ago

  • Milestone changed from 5.0 to 5.1

#21 @pento
5 years ago

  • Owner changed from SergeyBiryukov to pento
  • Status changed from reviewing to accepted

#22 @pento
5 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#23 @desrosj
5 years ago

  • Keywords has-dev-note added; commit removed
Note: See TracTickets for help on using tickets.