#18955 closed defect (bug) (fixed)
get_site_option caches default value when option does not exist
Reported by: | wpmuguru | Owned by: | duck_ |
---|---|---|---|
Milestone: | 3.3 | Priority: | normal |
Severity: | normal | Version: | 3.2.1 |
Component: | Multisite | Keywords: | has-patch |
Focuses: | Cc: |
Description (last modified by )
If get_site_option is passed any default value on a non-existent site option then a subsequent call to update_site_option will not add the site option. Because the site option does not exist, it does not get updated either. To reproduce
- in the sitemeta table edit the active_sitewide_plugins meta_key to be active_sitewide_plugins_x
- go to the network plugins screen and network activate any plugin
You get the message that the plugin was activated, but it doesn't because the site option doesn't get saved.
Options for fixing
- change the get_site_option in update_site_options to not use cache
- add a notsiteoption cache and cache the non-existence of the site option
- don't cache the default value in get_site_option
Option 1 is quick & easy
Option 2 is more work but is the way the blog options are handled and it would make things more consistent
Option 3 is probably not the preferable solution
Attachments (5)
Change History (21)
#2
@
13 years ago
18955.notoptions.diff worked fine for me. It's also the best solution to this, imo.
#3
@
13 years ago
We should also cache the non existence of site options in wp_load_core_site_options().
#6
@
13 years ago
ticket:18971:18971.01.patch implements option 1.
#9
@
13 years ago
Hey, I like option 3. :-) Why cache was is not in the DB? It also happens to be a small, beta-friendly patch.
#12
follow-up:
↓ 13
@
13 years ago
As discussed in IRC, 18955.op3.2.diff circumvents the filter at the end of the function. get_option() already behaves like this. We might make get_site_option() behave in the same fashion.
#13
in reply to:
↑ 12
@
13 years ago
Replying to ryan:
As discussed in IRC, 18955.op3.2.diff circumvents the filter at the end of the function. get_option() already behaves like this. We might make get_site_option() behave in the same fashion.
That looks fine to me although I would like to leave caching non-existence on the table for 3.4.
#14
@
13 years ago
- Owner set to duck_
- Resolution set to fixed
- Status changed from new to closed
In [19012]:
#15
@
13 years ago
18955.op3.2.diff would result in different behaviour for get_site_option() on singlesite vs multisite. When calling get_site_option( $option, 'default' ); for a non-existent option $option site_option_$option would run on singlesite, but not on multisite.
Therefore gone with 18955.opt3.diff per IRC.
As noted by your steps this bug requires code to ignore the site_option API to be triggered (so the DB and cache aren't in sync) and shouldn't happen in core.
Attached 18955.notoptions.diff example patch for adding a notoptions cache for site-options. I think this is the most sensible option. I'd say that 1 was the least preferable.