WordPress.org

Make WordPress Core

Opened 2 months ago

Closed 3 weeks ago

#46825 closed enhancement (wontfix)

Disable WSOD protection when WP_DEBUG is true

Reported by: arena Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.2
Component: Bootstrap/Load Keywords: servehappy
Focuses: Cc:

Description

define('WP_DEBUG', true);

Attachments (2)

46825.patch (1.2 KB) - added by aandrewdixon 2 months ago.
Patch sets define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); if debug mode is true, however, I had to move where debug mode is initialized up in wp-settings.php. It all still seems to work as expected.
46825.2.patch (658 bytes) - added by SergeyBiryukov 2 months ago.

Download all attachments as: .zip

Change History (38)

#1 @Clorith
2 months ago

Hiya,

I'm afraid I don't quite understand what the proposed change is here, would you mind providing some more information?

#2 @arena
2 months ago

Hi Clorith

Are you a coder ?
When you code, on your localhost,
Even how smart your code is,
It can crash the site ...

So the developper is aware of that

and do not need obfuscating messages such as

Your Site is Experiencing a Technical Issue
(and i have to check in my apache log which is a waste of time ...)

and receiving mails (not environmental friendly)
with subject : Your Site is Experiencing a Technical Issue
and content

Howdy,

Your site recently crashed on TBD and may not be working as expected.

This was caused by [my still on dev] plugin.

Click the link below to initiate recovery mode and fix the problem.

This link expires in 4 hours.

http://127.0.0.1/wordpress/wp-login.php?action=enter_recovery_mode&rm_key=grojCCZibuAJwwlVsmXVQe

Error Details
=============
An error of type E_ERROR was caused in line ... bla bla bla

What i already know because i read it in the apache log

Such a waste of time !

My dev site is using WP trunk version !

Last edited 2 months ago by arena (previous) (diff)

#3 @Clorith
2 months ago

  • Keywords servehappy added
  • Summary changed from Site Health : discard Site Health when ... to Disable WSOD protection on localhost

#4 @arena
2 months ago

  • Summary changed from Disable WSOD protection on localhost to Disable Site Health on any site when WP_DEBUG is true

No, wrong title.

You did not understand

Please read this

https://codex.wordpress.org/Debugging_in_WordPress

#5 @TimothyBlynJacobs
2 months ago

The email and message you are referring to is part of servehappy/WSOD protection as @Clorith indicated. This can be disabled by specifying the WP_DISABLE_FATAL_ERROR_HANDLER constant to your wp-config.php file.

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

#6 @TimothyBlynJacobs
2 months ago

  • Severity changed from critical to normal

#7 @arena
2 months ago

thank you

#8 @SergeyBiryukov
2 months ago

  • Component changed from General to Bootstrap/Load
  • Summary changed from Disable Site Health on any site when WP_DEBUG is true to Disable WSOD protection when WP_DEBUG is true

#9 @arena
2 months ago

  • Summary changed from Disable WSOD protection when WP_DEBUG is true to Discard SiteHealth when WP_DEBUG is true

Sorry but i have to change again the title.

PCHEALTH is slowing down my website !

@aandrewdixon
2 months ago

Patch sets define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); if debug mode is true, however, I had to move where debug mode is initialized up in wp-settings.php. It all still seems to work as expected.

#10 @ocean90
2 months ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 5.2
  • Summary changed from Discard SiteHealth when WP_DEBUG is true to Disable WSOD protection when WP_DEBUG is true

Moving to 5.2 for visibility.

@arena Please do not change the title again. Site health and fatal error protection are two separate features.

This ticket was mentioned in Slack in #core-php by tmdesigned. View the logs.


2 months ago

#12 @Clorith
2 months ago

  • Keywords has-patch removed

46825.patch doesn't account for users manually declaring the constant in their wp-config.php file. It's also a non-started to move the debug handler at this time, a substantial amount of processes run before the current placement of it, and it's too late in the 5.2 release cycle to be considering this.

I would also say there's a case to be made that you do not want these two features interconnected like this, I may want to enable debug mode to find a warning or conflict in some code, but I still want the WSOD protection to be functional.

#13 @afragen
2 months ago

I guess I’m not really certain of the utility of this. It’s simple enough to directly set the constant.

Additionally if you’re actually testing the WSOD protection and have WP_DEBUG enabled you wouldn’t be able to test.

#14 @aandrewdixon
2 months ago

True, my patch didn't take account of WP_DISABLE_FATAL_ERROR_HANDLER being defined and only worked by moving the initiation of debug mode.

The other way to do it would involve changing the handler to be a callback so that it could be unregistered after it has been registered, but I don't want to spend the time doing that if it is not agreed that this is something that is wanted, as from the comments there doesn't appear to be consensus.

My view would be, why would you want the fatal error handler to catch the error if you have debug mode enabled? Surely the whole point of debug mode is to see all errors and the debug output to help you fix it, not from them to be caught and suppressed by another mechanism.

#15 @xkon
2 months ago

I'm also on the side of keeping these separate as we have everything else for debugging in general. It's up to any given user to decide if they want to disable it or not for their specific reasons so it shouldn't be connected to something else.

#16 @TimothyBlynJacobs
2 months ago

Yep, I also think that the controls should be separate for the same reasons outlined.

We should make sure that if errors continue to be logged. We could also consider not printing the error handler template when WP_DEBUG and WP_DEBUG_DISPLAY is not set to false.

This ticket was mentioned in Slack in #core-php by schlessera. View the logs.


2 months ago

#18 @schlessera
2 months ago

  • Milestone 5.2 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

There's a general agreement that you can already disable this through a separate constant, and the two functionalities should stay independent of each other.

I'm closing this one as wontfix. Nevertheless, thanks for your report, @arena, it is appreciated.

Things to maybe consider as new tickets:

  • Add mention of the constant to the debugging docs.
  • Add sample setup to wp-config-sample.php of how to set the entire debugging/error-handling context based on the value of WP_DEBUG.

#19 @SergeyBiryukov
2 months ago

If this ever gets revisited, 46825.2.patch is a patch that accounts for users manually declaring the constant in their wp-config.php file, and does not require moving the debug handler around.

#20 @SergeyBiryukov
4 weeks ago

#47317 was marked as a duplicate.

#21 follow-up: @carasmo
4 weeks ago

I'm not sure how to correct this so it returns to the same behavior prior to this. I use

<?php
define( 'WP_DEBUG', true );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

But I still don't get any output on the site telling me what the error is. I also don't know whether or not the admin email is getting a notice still. I hope not.

But where do I set so I can see what the error is without having to look at the error_log? This is driving me nuts.

Thanks!

#22 in reply to: ↑ 21 ; follow-up: @afragen
4 weeks ago

Replying to carasmo:

I'm not sure how to correct this so it returns to the same behavior prior to this. I use

<?php
define( 'WP_DEBUG', true );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

But I still don't get any output on the site telling me what the error is. I also don't know whether or not the admin email is getting a notice still. I hope not.

But where do I set so I can see what the error is without having to look at the error_log? This is driving me nuts.

Thanks!

@carasmo take a look at WP Debugging. Makes setting all these constants easy and viewing debug.log easier.

#23 in reply to: ↑ 22 ; follow-up: @carasmo
4 weeks ago

Thanks! I am confused, though. I just want the old way where I could see the error on the page and the admin email does not get a report. Is there anything that does that now?

Replying to afragen:

Replying to carasmo:

I'm not sure how to correct this so it returns to the same behavior prior to this. I use

<?php
define( 'WP_DEBUG', true );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

But I still don't get any output on the site telling me what the error is. I also don't know whether or not the admin email is getting a notice still. I hope not.

But where do I set so I can see what the error is without having to look at the error_log? This is driving me nuts.

Thanks!

@carasmo take a look at WP Debugging. Makes setting all these constants easy and viewing debug.log easier.

#24 in reply to: ↑ 23 @afragen
4 weeks ago

Replying to carasmo:

Thanks! I am confused, though. I just want the old way where I could see the error on the page and the admin email does not get a report. Is there anything that does that now?

Replying to afragen:

Replying to carasmo:

I'm not sure how to correct this so it returns to the same behavior prior to this. I use

<?php
define( 'WP_DEBUG', true );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

But I still don't get any output on the site telling me what the error is. I also don't know whether or not the admin email is getting a notice still. I hope not.

But where do I set so I can see what the error is without having to look at the error_log? This is driving me nuts.

Thanks!

@carasmo take a look at WP Debugging. Makes setting all these constants easy and viewing debug.log easier.

Set define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); to disable the email and make sure WP_DEBUG_DISPLAY is true (default is true). That should show errors on page. Obviously not ideal to use in production.

All those an be set in the plugin settings.

Last edited 4 weeks ago by afragen (previous) (diff)

#25 @carasmo
4 weeks ago

@afragen. That's what I have in wp-config.php and since 5.2 I get no output on the frontend telling me anything I'm in dev still.

#26 @afragen
4 weeks ago

@carasmo what happens if you intentionally introduce an error or warning?

#27 @carasmo
4 weeks ago

@afragen It just shows in error log and the admin message is something like "your site is experiencing technical difficulties..." but I don't get any information other than that.

#28 @afragen
4 weeks ago

Seems like the WSOD protection is still active.

What you should see is a WSOD, at least for a fatal.

#29 @SergeyBiryukov
4 weeks ago

#47325 was marked as a duplicate.

#30 @SergeyBiryukov
4 weeks ago

  • Milestone set to 5.2.2
  • Resolution wontfix deleted
  • Status changed from closed to reopened

As seen in the related tickets above, the current behavior continues to cause some confusion.

Reopening to discuss 46825.2.patch.

#31 follow-up: @afragen
4 weeks ago

As I said in above this makes setting the constant specifically to false to debug the WSOD process rather onerous.

It shouldn’t be assumed that setting WP_DEBUG means other constants are also set to true. I haven’t looked but is there prior art for this sort of decision.

#32 @afragen
4 weeks ago

  • Type changed from defect (bug) to enhancement

Set as enhancement as it’s not really a bug.

#33 in reply to: ↑ 31 ; follow-up: @SergeyBiryukov
4 weeks ago

Replying to afragen:

As I said in above this makes setting the constant specifically to false to debug the WSOD process rather onerous.

I might be missing something, but wouldn't this be enough?

define( 'WP_DEBUG', true );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false );

The patch only defines the constant if it hasn't been explicitly defined earlier.

#34 in reply to: ↑ 33 @afragen
4 weeks ago

Replying to SergeyBiryukov:

Replying to afragen:

As I said in above this makes setting the constant specifically to false to debug the WSOD process rather onerous.

I might be missing something, but wouldn't this be enough?

define( 'WP_DEBUG', true );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false );

The patch only defines the constant if it hasn't been explicitly defined earlier.

I guess my point is having the developer declare the constant as false when debugging as they would likely already declared WP_DEBUG as true. Seems like simply transferring the burden of defining the constant to another person.

If I choose to have WP_DEBUG true this patch requires me to define the WSOD bypass constant in some way, even if I was happy with it being undefined.

This ticket was mentioned in Slack in #core-php by spacedmonkey. View the logs.


3 weeks ago

#36 @spacedmonkey
3 weeks ago

  • Milestone 5.2.2 deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

@afragen and I are maintainers of this code. I am closing as wontfix as they are existing working arounds.

Note: See TracTickets for help on using tickets.