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.

[duck_]

I think this would be fixed by fixing #18955.

[boonebgorges]

Yes, I think this is probably a duplicate of #18955 - I missed it when I searched before opening a new ticket. My patch is essentially wpmuguru's option 1; the patches on that ticket go for the more extensive option 2. Feel free to close as duplicate, though I think the severity should be higher than normal, as the current situation means that new MS installs can't network activate plugins at all.

[SergeyBiryukov]

Noticed this too, but couldn't reproduce a week after, and thought it was fixed at some point.

Moving #18955 to 3.3.