[wp-trac] [WordPress Trac] #44458: Catch WSODs and provide a means for recovery for end users
noreply at wordpress.org
Tue Oct 2 17:39:25 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.0
Component: Bootstrap/Load | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-unit-tests needs- | Focuses: multisite
Comment (by flixos90):
We discussed this ticket in multisite office-hours today. Here are our
* It should be possible to resume plugins for a regular site administrator
in every case, since the paused plugins are stored per site (and that
should continue to happen). Therefore, in `map_meta_cap()`,
`resume_plugin` should receive its own case where it always maps to
`activate_plugins`, no matter what (without the extra network handling the
other plugin capabilities have).
* Network-active plugins should also look at the list of paused plugins
and be paused accordingly. We explicitly decided that, even though these
plugins are network-active, they should still only be paused per site as
it might be due to a conflict with another plugin that is only active on
* As a follow-up to the above two points, in the admin plugins list table,
the Resume Execution link must also be added for network-active plugins
that are paused.
* MU-plugins should be skipped entirely from the WSOD protection. We
primarily implement this feature for less tech-savvy users, and those
should never use MU-plugins, unless it's those default ones from their
hosting provider, and those shouldn't cause errors (and otherwise the
hosting provider would quickly be aware). MU-plugins often contain
critical functionality, which might be security-related and their name
indicates that they are must-use. Also, less things to implement for us.
We should skip those entirely.
* The option `pause_on_admin` should be split into separate options for
plugins and themes. `pause_on_admin` is not an accurate name since there
are other protected endpoints too. We suggest having two options of
serialized arrays, `paused_plugins` and `paused_themes`. Wrapper functions
`add_paused_plugin( $plugin, $error )`, `remove_paused_plugin( $plugin )`,
`get_paused_plugins()`, `add_paused_theme( $theme, $error )`,
`remove_paused_theme( $theme )`, `get_paused_themes()` should be added.
Alternatively use `set_*` and `unset_*` for the names instead of `add_*`
* The main benefit of the above separation and abstraction is the
following: A major need for multisite would be a way for a network
administrator to be notified/aware of issues caused by plugins, since they
are the only ones with the permissions to fix the issues most likely. On
multisite, the paused plugins and themes should not be stored in a
`paused_plugins` / `paused_themes` option - instead the new `blogmeta`
table (i.e. site metadata) should be used, which enables the network admin
panel to query:
* which/how many sites do have paused plugins?
* which/how many sites do have paused themes?
* which/how many sites do have plugin x paused?
* which/how many sites do have theme y paused?
* The above queries being possible allow us to implement a cron hook that
sends a notification email based on the paused plugins and themes on the
network to the network administrator/s, with information for each
plugin/theme for how many or even which sites are affected.
* In the future, it might be useful to allow network administrators to
automatically resume a plugin for the entire network, which would also be
made possible by using `blogmeta` (site metadata). This would be v2
I'll wait for a few days to get some initial feedback on the above
suggestions, and then will start implementing something along these lines.
I should have most of the changes done by next week's meeting so that we
can review then - having the code might also help in making a decision.
Ticket URL: <https://core.trac.wordpress.org/ticket/44458#comment:36>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac