id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
18971	add_site_option() and update_site_option() not working correctly when non-false default is loaded into the cache	boonebgorges		"I recently discovered that on a fresh installation of WP 3.3-bleeding (r18972), it was impossible to Network Activate a plugin. After tracing the problem for a while, I found that it's related to the change, implemented in r18588, to using get_site_option() instead of a direct db query to check for existing content.

To be more specific, when you use get_site_option() (as at http://core.trac.wordpress.org/browser/trunk/wp-includes/functions.php?annotate=blame&rev=18923#L3843), you hit the cache before querying the DB. In the case of active_sitewide_plugins (and perhaps other sitemeta keys, though this is the one that caused me a problem), the queried value is already cached by the time it's called by activate_plugin(). The problem in the case of activate_sitewide_plugins, however, is that it is originally called like this:

{{{get_site_option( 'active_sitewide_plugins', array() );}}}

which means that the value in the cache is an empty array. This, in turn, means that the {{{false===}}} check at http://core.trac.wordpress.org/browser/trunk/wp-includes/functions.php?annotate=blame&rev=18923#L3843 will always fail, and the option will never be added. Thus, you can never network activate a plugin.

There are a couple of ways that the problem might be addressed, but I think the most straightforward (and lowest impact) is to simply skip the cache when using get_site_option() inside of add_site_option() and update_site_option(). See 01.patch.
"	defect (bug)	closed	normal		Multisite	3.3	critical	duplicate	has-patch