Make WordPress Core

Opened 7 years ago

Last modified 10 months ago

#18391 reopened enhancement

Expand WP_DEBUG_LOG and make WP_DEBUG_DISPLAY work as expected

Reported by: nacin Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Bootstrap/Load Keywords: has-patch
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 (3)

18391.diff (2.4 KB) - added by nacin 7 years ago.
18391.patch (887 bytes) - added by sebastian.pisula 2 years ago.
18391.2.diff (962 bytes) - added by ethitter 10 months ago.

Download all attachments as: .zip

Change History (16)

7 years ago

#1 @nacin
7 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
7 years ago

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

#3 in reply to: ↑ 2 @duck_
7 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
6 years ago

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

Second part is WP_DEBUG_LOG?

#5 @nacin
6 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
4 years ago

  • Component changed from General to Bootstrap/Load

#7 @chriscct7
2 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
2 years ago

#34441 was marked as a duplicate.

#9 @sebastian.pisula
2 years ago

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

#10 @sebastian.pisula
2 years ago

I add patch for 4.5-beta1-36775

#11 @SergeyBiryukov
2 years ago

  • Milestone set to Awaiting Review

#12 @dd32
17 months ago

#38735 was marked as a duplicate.

10 months ago

#13 @ethitter
10 months 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.

Note: See TracTickets for help on using tickets.