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

 The second iteration contains basic UI integration, but currently only for
 plugins.

 On the frontend, when an error is triggered, WordPress will display a
 corresponding message, and provide a link to log into the admin dashboard
 to fix the issue.

 The message is filterable via {{{'wp_technical_issues_display'}}}, and the
 entire page can be replaced via a drop-in called {{{php-error.php}}}.

 [[Image(https://i.imgur.com/S06ErFV.png)]]

 Then, once the site owner has logged into the admin backend, they see an
 admin notice letting them know about the problem and providing a link to
 go to the plugins screen to manipulate the plugins.

 [[Image(https://i.imgur.com/alGWnNQ.png)]]

 Finally, once they are on the Plugins screen, they can see the plugins
 that have been "paused" within the admin backend because of an error. The
 site owner will be able to do all sorts of manipulations, like updating
 the plugin, deactivating it, deleting, etc... Once the site owner thinks
 they solved th problem, they can choose to "Resume execution" for the
 problematic plugin. If the plugin still contains an error, it will be
 caught and recorded again.

 [[Image(https://i.imgur.com/y3k8ZDc.png)]]

 Questions & remaining issues:

 - We should decide on specific language (on the technical side just as
 well as facing the site owners). Right now, the code talks about "pausing"
 a plugin and "resuming its execution" (with caps like
 {{{'resume_plugin'}}} and similar).
 - Once the language has been decided, we should implement the same UI
 mechanisms for themes as well.
 - Multisite has been largely ignored for now. This will probably require
 specific handling of network-activated plugins.
 - We need to decide whether must-use plugins should be pausable or not. I
 have no clear answer for this yet.
 - In an event like a PHP update, multiple plugins might break at the same
 time. This would lead to a very confusing back & forth until all
 problematic plugins have been properly detected. We should think about how
 we can handle this (an AJAX loop with the paused plugins actually paused,
 to detect new issues?).

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