[wp-trac] [WordPress Trac] #44458: Catch WSODs and provide a means for recovery for end users

[WordPress Trac]

#44458: Catch WSODs and provide a means for recovery for end users
-------------------------------------------------+-------------------------
 Reporter:  schlessera                           |       Owner:  (none)
     Type:  task (blessed)                       |      Status:  new
 Priority:  normal                               |   Milestone:  5.0
Component:  Bootstrap/Load                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-unit-tests needs-    |     Focuses:  multisite
  testing                                        |
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Replying to [comment:29 bradleyt]:
 > In `plugin.php` "shutdown-handler" is listed without the ".php", which
 is inconsistent with the other drop-in files

 Good catch!

 > It feels like a shame that `is_protected_endpoint` is not filterable, to
 allow plugin authors to specify their own critical routes. (For example,
 an SEO plugin may wish to ensure `robots.txt` is correctly returned even
 if the site enters safe-mode)

 I agree a filter would be valuable. However it should not be possible to
 alter the default protected endpoints, to make them "unprotected" as this
 could have severe results.

 > In `wp_shutdown_handler_wrapper` you check if the options API has been
 loaded before trying to load `php-error.php` which feels like a mistake to
 me (why would you not want a custom error page, even if the issue cannot
 be recorded)

 This is a tricky one. I think the decision on this depends on whether we
 see the new 500 error markup as something that should always be rendered
 in case a WSOD would otherwise occur, or whether we see it as something
 that should only be rendered in case we can actually do something about it
 and point the user to the admin area where they can fix the issue. I'm not
 sure about this one yet.

 > You suggest that custom `php-error.php` pages should `die()` so that the
 default `wp_die()` is not run. However, this means that sites with a
 custom `php-error.php` won't get the `is_protected_endpoint` redirect loop
 which feels a shame.

 I think the redirect logic should be executed before it is checked whether
 a `php-error.php` drop-in exists. This would maintain support for the
 redirects in all cases, and furthermore make more obvious that `php-
 error.php` is simply a template that should output (status) headers and
 markup, similar to the existing `db-error.php` for example.

 > You default to HTTPS if `is_ssl` has not been loaded - This feels like a
 mistake as if the server does not have HTTPs setup they will be redirected
 to a browser error page, with no indication of what went wrong. As this
 feature is targeted at less advanced users, it feels more sensible to not
 do the redirect at all if is_ssl is not available.

 I actually think this check can be removed as `is_ssl()` is always
 available when the shutdown handler is active, since it is part of the
 `load.php` file as well.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44458#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform