Errors displayed on shutdown handler

[spacedmonkey]

PHP errors are displayed on shutdown handler screen for REST API requests.

See attached screenshot.

[spacedmonkey]

This also happens on RSS feeds

[spacedmonkey]

All appears on wp-trackback.php

[spacedmonkey]

All appears on wp-link-opml.php

[spacedmonkey]

Also appears on wp-signup.php

[afragen]

Isn't this because WP_DEBUG and WP_DEBUG_DISPLAY are both true?

[spacedmonkey]

Nope, there are not setup like this. Screenshot below.

[spacedmonkey]

The issue is related to ​this line, that only hide errors on some conditions. Above is a list of conditions that public facing but are not XMLRPC_REQUEST, REST_REQUEST, WP_INSTALLING, Admin ajax or a JSON request.

[afragen]

Thanks for the explanation.

[spacedmonkey]

45958.diff first patch.

Simple change, just don't display error message for all requests.

[schlessera]

I think the patch breaks the WP_DISPLAY_DEBUG constant, as it is set early, and you're now overriding it no matter what. This line is meant to represent the exceptions for WP_DISPLAY_DEBUG is actually set to true. In such a case, the filtered requests you saw in the changed line here still need to not display anything to avoid breaking the response.

I had already looked into this as well, and the main problem is that the shutdown handler should decide whether or not to display the error, but at the moment the shutdown handler receives control, PHP has already printed the error.

[pento]

Adding to the 5.1 milestone for tracking.

[flixos90]

This issue is not related to any changes made by or for Servehappy, therefore it's not relevant for the 5.1 milestone. Even without having the new PHP error template, that message would have been printed out if the server is configured like that.

The problem here is, as pointed out before, that WordPress does not actually disable displaying errors, even when WP_DEBUG_DISPLAY is not true. It only does so for some request types, for example AJAX requests. As far as I'm aware the issue has been raised before, but not been considered valid, as the server configuration should be responsible for that. I'm personally open to revisiting this, but it's not related to Servehappy, therefore I'll put it back to Awaiting Review.

[SergeyBiryukov]

Is this still relevant after #45989?

[spacedmonkey]

@SergeyBiryukov still valid, it is about the errors showing at all. See the screenshots.