add_site_option() and update_site_option() not working correctly when non-false default is loaded into the cache
|Reported by:||boonebgorges||Owned by:|
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.