![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 15 years ago
Closed 15 years ago
#18971 closed defect (bug) (duplicate)
add_site_option() and update_site_option() not working correctly when non-false default is loaded into the cache
| Reported by: | boonebgorges | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Multisite | Version: | 3.3 |
| Severity: | critical | Keywords: | has-patch |
| Cc: | Focuses: |
Description
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.
Attachments (1)
Change History (5)
#3
@
15 years ago
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.
I think this would be fixed by fixing #18955.