[wp-trac] [WordPress Trac] #15548: Cache inconsistencies between get_option and get_blog_option

WordPress Trac wp-trac at lists.automattic.com
Tue Nov 23 08:28:34 UTC 2010


#15548: Cache inconsistencies between get_option and get_blog_option
--------------------------+-------------------------------------------------
 Reporter:  mwidmann      |       Owner:                   
     Type:  defect (bug)  |      Status:  new              
 Priority:  normal        |   Milestone:  Awaiting Review  
Component:  Multisite     |     Version:  3.0.1            
 Severity:  normal        |    Keywords:  caching, memcache
--------------------------+-------------------------------------------------
 When an option is updated for a blog {{{update_option}}} calls
 {{{wp_cache_set}}} to update the cache for that option.

 The problem comes when the option is accessed through
 {{{get_blog_option}}} from another site. There the cache never gets
 updated (unless the caching - in our case memcached - is recycled.

 Steps to reproduce, I'm updating the {{{admin_email}}}, so be sure to
 change it back afterwards:

 {{{
 echo "fetching using get_blog_option<br>";
 echo get_blog_option( 6, 'admin_email' );

 switch_to_blog( 6 );
 echo "<br>fetching using get_option before update<br>";
 echo get_option( 'admin_email' );
 echo "<br>updating...<br>";
 update_option( 'admin_email', 'new-value at email.com' );
 echo "<br>fetching using get_option after update<br>";
 echo get_option( 'admin_email' );
 restore_current_blog();

 echo "<br>fetching using get_blog_option after uptdate<br>";
 echo get_blog_option( 6, 'admin_email' );
 }}}

 The output will look like something similar to this:

 {{{
 fetching using get_blog_option
 old-value at email.com
 fetching using get_option before update
 new-value at email.com
 updating...

 fetching using get_option after update
 new-value at email.com
 fetching using get_blog_option after uptdate
 old-value at email.com
 }}}

 If no caching is enabled than - of  course - this issue doesn't come up as
 the value is always fetched form the database.

 The best solution most probably would be to modify the either hook into
 {{{update_option}}} and {{{delete_option}}} actions from {{{ms-
 blogs.php}}} and then update or delete the value based on the given
 option.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15548>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list