Disable WSOD protection when WP_DEBUG is true

[arena]

define('WP_DEBUG', true);

[Clorith]

Hiya,

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

[arena]

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 !

[arena]

No, wrong title.

You did not understand

Please read this

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

[TimothyBlynJacobs]

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 );

[arena]

thank you

[arena]

Sorry but i have to change again the title.

PCHEALTH is slowing down my website !

[aandrewdixon]

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.

[ocean90]

Moving to 5.2 for visibility.

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

[Clorith]

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.

[afragen]

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.

[aandrewdixon]

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.

[xkon]

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.

[TimothyBlynJacobs]

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.

[schlessera]

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.

[SergeyBiryukov]

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.

[SergeyBiryukov]

#47317 was marked as a duplicate.

[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!

[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.

[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.

[afragen]

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.

[carasmo]

@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.

[afragen]

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

[carasmo]

@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.

[afragen]

Seems like the WSOD protection is still active.

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

[SergeyBiryukov]

#47325 was marked as a duplicate.

[SergeyBiryukov]

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

Reopening to discuss 46825.2.patch​.

[afragen]

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.

[afragen]

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

[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.

[afragen]

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.

[spacedmonkey]

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