[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:                  |     Focuses:
----------------------------+---------------------

Comment (by schlessera):

 I uploaded a first proof-of-concept of the safe mode mechanism.

 I had to find out that the `debug_backtrace` is useless, as the stack is
 completely unrolled before the shutdown handler is being called.

 However, `error_get_last()` returns both the type of error as well as the
 file where it was triggered in.

 With that information, we can do some deduction, like a parse error only
 ever happens in the file that is actually the cause of the problem, so
 that can be directly tied to a plugin/mu-plugin/theme.

 Also, I built it so that it can be customized on sites just like with
 `advanced-cache.php`. You can drop a `shutdown-handler.php` file into the
 `wp-contents` folder that provides a `wp_handle_shutdown()` function. This
 lets you customize/override/disable the shutdown handling logic.

 I'm currently adding the detected culprits to a DB option called
 `skip_on_admin`. When loading the admin or when you're on the login page,
 these plugins/mu-plugins/themes will always be skipped until you manually
 declare them to be safe again.

 The front-end will not be impacted at all by this. We're only filtering
 the loading of these when we're inside the admin backend.

 The basic system seems to work. When I produce a parse error in a plugin,
 my frontend breaks and I get a WSOD. The plugin that causes the error is
 stored in the DB in the `skip_on_admin` option, though. Then, when I go to
 either a login or an admin screen, that particular plugin is filtered out
 of the active plugins list and doesn't get loaded. So although the
 frontend is broken and shows a WSOD, logging in and working in the admin
 backend still works correctly.

 What needs to be added now is:
 - an admin notice to let the user know that something is broken
 - an integration into the plugin list that lets the user remove the plugin
 from the `skip_on_admin` list.

 Also, I'm still not sure whether I should include must-use plugins in that
 mechanism or not...

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