[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