WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 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:
Milestone: Priority: normal
Severity: critical Version: 3.3
Component: Multisite Keywords: has-patch
Focuses: Cc:

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)

18971.01.patch (771 bytes) - added by boonebgorges 3 years ago.

Download all attachments as: .zip

Change History (5)

boonebgorges3 years ago

comment:1 SergeyBiryukov3 years ago

  • Milestone changed from Awaiting Review to 3.3

comment:2 duck_3 years ago

I think this would be fixed by fixing #18955.

comment:3 boonebgorges3 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.

comment:4 SergeyBiryukov3 years ago

  • Milestone 3.3 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

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

Moving #18955 to 3.3.

Note: See TracTickets for help on using tickets.