WordPress MU

In a plugin I'm developing, I'm pulling the current blog theme using get_blog_option( $blog_id, 'template' );

The first time it's called, it gets stored in the object cache using wordpress internal caching (not talking about a plugin here). The problem I see is when the user changes their theme to a different one, the value pulled will still be the old cached one. Shouldn't the cache be reset (or updated) when the user changes themes, in order to update this new value?

Would having a look at our theme stats plugin help any?
http://wpmudevorg.wordpress.com/project/Theme-Stats

Because the cache should update (even object cache I would think) when the user picks a new theme and that gets written to the db.

Well i modified my code to pull directly from the database instead because I can't risk getting the wrong value, but i'm going to do some more testing to figure out if it's a bug or perhaps was just a delay.

If it's 1.3.3, and not the latest from Trac, Object cache is hosed.

Anything later then like r1195 (or was it 1196?) has it fixed. Note that those were after the 1.3.3 tag though.

I'm latest right up to the point before the WP 2.5 files were added, which means i'm pretty sure the files i'm using are running the fixed cache.

This definitely isn't a delayed bug. It's almost a 50/50 chance that the cache gets flushed/updated. Take a look at my test blog, i've added some visual debug that includes the cached key name, cached value of 'template', and an SQL pulled value of 'template'.

http://testing.paidtoblog.com/

This is updated to revision 1213 which includes the cache fixes. Code looks like this: http://pastebin.com/m4bc66cbc

I'm a bit worried this bug will apply to all the blog_options, so i'm turning off caching all together. There is definitely something wrong. I tested by switching the theme back and forth between the default theme and another one called ProSense. About half the time, the cache value would not change while the database value did.

I put this in trac a while back when 1.3.3 was hosed up.

"Just for reference, reverting back to cache.php prior to r1187 (r1125), and then applying the suggested fix in [trac ticket] #542 works just fine.

In light of the severe issues with the r1187 version, that seems to be the best work around for the time being."

Can you give that a spin and see what happens?

I haven't noticed any issues with that "workaround", but you never know.

Thanks luna, i'll give that a go and see what happens.

Reverted the cache.php file to r1125 and applied the mentioned fix on line 171. Surprisingly, the result is still the same. I switched the themes back and forth a few times and it behaves the same way. I added a ticket to trac as I don't have enough knowledge of how the cache works to pinpoint the problem.

Could just be that a theme switch doesn't refresh the object cache.

I don't know if it ever has, honestly. Not something I've needed to dig into, really.

Taking a look at wp-admin/theme.php, it updates the 'template' and 'stylesheet' using the update_option function. This COULD indicate a caching problem with any other part of WPMU that uses update_option.

rev 1201 seems to have fixed the original cache problem for me.

Trent

This also affected Blog Links for me. Blog links would neither be created or deleted with object cache on.