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

 We discussed this ticket in multisite office-hours today. Here are our
 thoughts:

 * 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
 that site.
 * 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_*`
 and `remove_*`.
 * 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
 material though.

 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