[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):

 [attachment:"44458.8.diff"] makes the following adjustments:

 * Fix `shutdown-handler` to appear as `shutdown-handler.php` in drop-ins
 list.
 * Always show PHP error page even if the recorded error could not be
 persisted.
 * Introduce `is_protected_endpoint` filter that allows providing further
 protected endpoints in addition to core's.
 * Remove unnecessary `function_exists()` checks for
 `is_protected_endpoint()` and `is_ssl()`, since those reside in the same
 file.
 * Ensure that, even when using a custom `php-error.php` template, the
 redirect routine for detecting multiple errors in one go fires. Make
 including that template similar to how `db-error.php` is handled: It
 should control the HTTP status code and print markup (either through
 custom HTML or `wp_die()`).
 * Fix WP Coding Standard violations and minor tweaks.

 As always, for details please refer to https://github.com/wp-core-php
 /wordpress-develop/pull/3 where you can see individual commits.

 A few more things to consider:
 * We need to figure out whether we want to show the error page if the
 detected error could not be recorded successfully.
 `wp_record_extension_error()` already returns a boolean to indicate
 success or failure, which we don't use at the moment. We could though.
 * In the same trail of thought, I haven't played this through yet, but I
 think we can possibly run into a redirect loop right now if the error
 could not be recorded.

 I think in multisite the `resume_plugin` capability should not be tied to
 whether the user can activate a plugin in a multisite. Plugins are
 currently paused only for a site, so I'd argue that means a site
 administrator should already have access to resume one. We would also need
 to adjust the plugin row actions then, as in even when a plugin is network
 active, it should render a Resume execution link if the current user has
 the capabilities. Note that this is just an initial observation I made -
 we will discuss multisite compatibility in detail in today's office hours.

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