[wp-trac] [WordPress Trac] #37656: Improve plugin bootstrapping processes (was: Improve plugin bootstrapping processes with `WP_Plugin`)

[WordPress Trac]

#37656: Improve plugin bootstrapping processes
-------------------------+------------------------------
 Reporter:  flixos90     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  multisite
-------------------------+------------------------------
Changes (by flixos90):

 * focuses:   => multisite


Comment:

 Replying to [comment:3 swissspidy]:
 > Starting small has probably the highest chance of getting this into
 core, i.e. a `WP_Plugin` class analogous to `WP_Theme`. Forgetting #21883
 and `register_plugin()` in the beginning.
 >
 > While `register_plugin()` and an additional interface sounds
 interesting, I do not think anyone would use it because of backward
 compatibility with older WordPress versions. Who wants to basically
 maintain two versions of their plugin?

 Tbh I would like this ticket to go more into the direction of the latter.
 I agree that `WP_Plugin` shouldn't be used as the class name for this
 (because like you said it should rather have parity with `WP_Theme`),
 however I think there are two different tasks here which are not really
 related to each other. `WP_Plugin` as we talked about it now should be
 handled in a separate ticket.

 About this ticket, maybe we can find a way to improve plugin setup
 processes in a way like @jdgrimes mentioned. I actually like the idea of
 handling network-wide activation in Core. Maybe it could be like the
 following:

 * if plugin is activated network-wide, ...
     * detect whether the plugin has hooked into a (new) action
 `activate_{$plugin_basename}_for_site`; if it has, automatically iterate
 through the sites in the network (only if not `wp_is_large_network(
 'sites' )`) and run `activate_{$plugin_basename}_for_site` on each site
     * in addition, run another (new) action
 `activate_{$plugin_basename}_for_network` which the plugin developer can
 hook into to perform network-wide activation stuff (probably a minor
 number of plugins needs that, only those that actual deal with multisite
 stuff)
 * if the plugin is activated on a single site, ...
     * only run the `activate_{$plugin_basename}_for_site` hook

 The existing `activate_{$plugin_basename}` hook would stay completely
 unaffected by this. It would still run as before. The new ways would
 become the new best practice though.

 Deactivation could work similarly. For uninstallation we would need to
 think a bit more on what's the best way to implement a similar solution in
 Core or whether it should remain as is for now.

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