[wp-trac] [WordPress Trac] #44458: Catch WSODs and provide a means for recovery for end users

WordPress Trac noreply at wordpress.org
Wed Dec 19 15:47:33 UTC 2018


#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.1
Component:  Bootstrap/Load                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-unit-tests needs-    |     Focuses:  multisite
  testing servehappy                             |
-------------------------------------------------+-------------------------

Comment (by vizkr):

 Replying to [comment:12 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...
 >

 This is a valid point. Most mu-plugins I use are installed by me directly,
 however WP Engine does include their own suite and WP Migrate DB Pro also
 installs a mu-plugin of their own. However in my opinion this is a bonus
 item and probably not a MVP requirement.

 > > 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:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list