[wp-trac] [WordPress Trac] #53255: WordPress multisite allows you to delete plugins which are active on some subdomains

WordPress Trac noreply at wordpress.org
Fri Jun 5 09:03:46 UTC 2026


#53255: WordPress multisite allows you to delete plugins which are active on some
subdomains
-------------------------------------+-------------------------------------
 Reporter:  denisflorin197           |       Owner:  (none)
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Plugins                  |     Version:  4.6
 Severity:  critical                 |  Resolution:
 Keywords:  has-patch has-unit-      |     Focuses:  administration,
  tests has-screenshots              |  multisite
-------------------------------------+-------------------------------------

Comment (by tippl):

 Replying to [comment:7 desrosj]:
 > Thank you @tippl for this contribution!
 >
 > I discussed with @bernhard-reiter a bit today at WordCamp Europe
 Contributor Day. A few bullet points.
 > - The notice should be updated to ''always'' warn the user in the
 confirmation message that the plugin may have been activated for
 individual sites on the network.
 > - I am a bit concerned with scanning every site to count the number of
 subsites that have activated the plugin. This will not scale, especially
 every time the Plugins page on the Network Admin is loaded.
 > - There is not a good way to query across multiple tables at the same
 time, so that's out.
 >
 > I'm not convinced yet, but I think the only way this works is if there a
 network option is added that contains a multidimensional array of site IDs
 keyed by plugin slug:
 >
 > {{{
 > array(
 >       'hello-dolly/hello.php' => array(
 >               1,
 >               2,
 >               3,
 >       ),
 >       'ai-by-jonathan' => array(
 >               4,
 >               5,
 >               6,
 >       ),
 > );
 > }}}
 >
 > Each time a sub site activates or deactivates a plugin, the option is
 updated accordingly. However, this would require the option to be hydrated
 the next time the network upgrade is run.

 Thank you for the detailed feedback! I understand the performance concerns
 with large networks. The solution was a first step, but I agree it doesn't
 scale well.

 The network option approach makes sense to me. I'm not sure I have the
 experience yet to implement the full migration/hydration part correctly.

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


More information about the wp-trac mailing list