[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