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

 > 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.

 I'm not sure that is the case. I think right now, we cover already 60-70%
 of the needed code. Half of the multisite plugin stuff is already covered,
 and themes can mostly reuse the same code.

 > I would advise against this, for three reasons:
 > 1. MU plugins often contain very foundational functionality of a
 website.
 > 2. Someone who uses MU plugins usually has a little more technical
 knowledge than who the safe mode is most beneficial for.
 > 3. 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.

 I'm not entirely sure these are valid reasons.

 1. Yes, but a parse error means they just take down the site either way.
 The importance of the plugin is irrelevant in that case.
 2. Sometimes MU plugins ar not installed by the site owner themselves, but
 by hosting or another plugin.
 3. This is the only argument that plays a role here I think. What's the
 point of making people enter th eplugin screen if they have no valid
 options. I wonder though (not tested yet) whether they could modify the MU
 plugin through the built in code editor...

 > 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.

 Yes, agree.

 > 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.

 Yes, I had already thought about adding something like that. It could be
 similar to the Shiny Updates plugin, where it triggers a sandboxed request
 to see whether the plugin now works correctly again.

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