[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                                        |
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * keywords:   => has-patch needs-unit-tests needs-testing
 * focuses:   => multisite


Comment:

 Replying to [comment:9 schlessera]:
 > The second iteration contains basic UI integration, but currently only
 for plugins.
 I really like the direction this approach is going, thanks for doing all
 that work on it!

 > - 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.
 I can see this project becoming really big and complex for a single patch
 and commit. In order to maintain a good overview as well as easy workflow,
 I think it would be a good idea to move work on this over to a GitHub fork
 of WordPress. Then we can handle the respective integrations with themes,
 multisite and possibly MU plugins via separate branches/PRs.

 > - We need to decide whether must-use plugins should be pausable or not.
 I have no clear answer for this yet.
 I would advise against this, for three reasons:
 * MU plugins often contain very foundational functionality of a website.
 * Someone who uses MU plugins usually has a little more technical
 knowledge than who the safe mode is most beneficial for.
 * There is no way to manage MU plugins through the admin. Of course we
 could introduce a way to resume a MU plugin, but for the two previous
 reasons, I don't think it's worth the hassle.

 > - 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?).
 For now, in my opinion we should try to focus on detecting in the most
 accurate way possible which plugin(s) or theme(s) are causing the error.
 An AJAX loop is what I thought about too.

 A general suggestion for improvement I have is that we should consider
 keeping the user in the backend when they are already there while
 something breaks. For example, if you're in the Plugins screen, resuming a
 plugin, and then it's still broken, it would be great if the user could
 automatically stay on that page, getting the feedback message there that
 it was paused again (instead of seeing the message like in the frontend
 and having to click a link). We could try to redirect the user to the page
 they're currently on after pausing the broken plugin(s) and theme(s), if
 that is already a logged-in admin page. Of course this only works under
 certain circumstances, if we know who the current user is and if we're
 still before output. This could very well happen a little later, when we
 improve the UX further.

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