[wp-trac] [WordPress Trac] #50850: When the deactivate_plugins() function is called in the ABSPATH/wp-admin/includes/plugin.php file, the is_plugin_active_for_network() conditional tag always returns true when the active_sitewide_plugins sitemeta option is set to 1

[WordPress Trac]

#50850: When the deactivate_plugins() function is called in the ABSPATH/wp-
admin/includes/plugin.php file, the is_plugin_active_for_network()
conditional tag always returns true when the active_sitewide_plugins
sitemeta option is set to 1
--------------------------+------------------------------
 Reporter:  zenithcity    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Plugins       |     Version:  5.4.2
 Severity:  critical      |  Resolution:
 Keywords:  needs-patch   |     Focuses:  multisite
--------------------------+------------------------------

Comment (by SergeyBiryukov):

 Hi there, welcome to WordPress Trac! Thanks for the report and the patch.

 > On multisite during the process of activating a plugin across the
 network (sitewide plugin activation), I noticed that if the activation
 process is not successful or if errors are triggered, the
 `active_sitewide_plugins' sitemeta option will be set to 1

 I could not reproduce a path in core where `active_sitewide_plugins` would
 be set to 1. It's only updated in [source:tags/5.4.2/src/wp-
 admin/includes/plugin.php?marks=694-696#L692 activate_plugin()] and
 [source:tags/5.4.2/src/wp-admin/includes/plugin.php?marks=833-835#L829
 deactivate_plugins()], with both instances receiving an array.

 Adding some protection against an invalid value sounds good in general,
 but this doesn't seem any different from accidentally setting an invalid
 value for any other option that should always be an array:
 `active_plugins`, `recently_activated`, `recently_edited`,
 `uninstall_plugins`, `*_paused_extensions`, `recovery_keys`,
 `theme_mods_*`, `nav_menu_options`, `sticky_posts`, to name a few.

 So far this seems like a plugin error. If there is a path in core where
 setting `active_sitewide_plugins` to 1 can be easily reproduced with a
 specific example, demonstrating that would probably be a good idea for the
 ticket to move forward.

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