Object Cache Not Updating

Are you using the bog standard caching in wp-content/cache/ or something else like xcache or memcached? I tried to replicate this using the filesystem cache but it worked ok for me and the post updated when I saved it.

No fancy caching at all. Pure object cache, on disk.

The database does update, but the cache isn't refreshed. So you see the cached query, with the old data, and not the new one.

Example to reproduce:

Edit a page. Click save. When it returns you to the manage page overview, click edit on the post again. It looks the same (in the post box content) as it did when you went to edit it the first time. (Visual editor is off.)

Another example. Go in and add some categories from the manage categories page. They pop up in the list through ajax, but then click that page again. They aren't there. Then, try to make a post. Again, they're not in the list in the sidebar.

Clear object cache (rm -rf *), and all is well.

This has been observed on several platforms and sites.

Confirmed with r1195. It's also affecting categories. After writing a post where one adds in new categories, returning to the Write Post page, those new categories do not show up within the tab. (Although adding them in again works fine and the ID number is correct.) Remove the enable line for the object cache out of the config file and everything starts working again.

To add to this, another instance of the object cache not being updated.

Adding a comment to a site, under the same set-up as above, the recent comments list (sidebar, built-in widget) is not updated as it should be.

Clearing the object cache immediately corrects the issue.

// Aside: I'm going to bump this up in severity, as I'm finding more and more things affected. These instances being the case, there is something not recognizing that the cache should be updated. Specifically what, I can't say as I (unfortunately) haven't had the chance to dig deep and track it down. My best assumption at the moment is that it relates to the changes in r1187, or a combination of that and r1172 and r1196 as well.

I'm not sure if this is related, but I have been seeing something similar on another project of mine using MU 1.3.3.

I change something for my blog using update_option(KEY_NAME, KEY_VALUE). I'm able to retrieve the value using get_option(KEY_NAME), but not via get_blog_option(MY_BLOG_ID, KEY_NAME).

I am running memcached on my server. When I restart memcached, the new value is returned the first time. If I save the option again and try to retrieve, however, the old value is returned.

Commenting out the following lines in my wp-config.php file didn't seem to help either:

//$memcached_servers = array('127.0.0.1:11211'); //define( 'ENABLE_CACHE', true);

I had to remove the symbolic links for memcached-client.php and object-cache.php from wp-content in order to use the standard object caching system.

If memcached is not running, or if I'm removed all traces of using memcache from WPMU, things work as expected.

Here a way to reproduce the problem on my end:

<?php

global $blog_id;

$my_blog_id = 3; // Change this to the id of your blog

$my_blog_option = 'my_option_name'; // Change this to the key name of your option

echo "Using get_blog_option: " . get_blog_option($my_blog_id, $my_blog_option) . '<br />';

$original_blog = $blog_id;

switch_to_blog($my_blog_id);

echo "switch_to_blog and then get_option: " . get_option($my_blog_option) . '<br />';

$blog_id = $original_blog;

switch_to_blog($blog_id);

?>

Change the option and then you'll see a difference in the two values.

Hope this helps.

Also appears to be affecting blogroll links.

http://mu.wordpress.org/forums/topic.php?id=7571

I can confirm the problem in MU 1.3.3 when the user edits a page with attachments. I have tracked my specific problem to _fix_attachment_links in wp-admin/includes/post.php where the system gets the page again after updating the database from the cache but what it gets is the old version. As i am not some kind of Wordpress guru nor I have time my fix was to add there two lines to the beginning of _fix_attachment_links:

global $wp_object_cache;
$wp_object_cache->cache = array();

Ugly, but it worked (i think). I hope that official fix for the overall problem will be nicer :)

Just for reference, reverting back to cache.php prior to r1187 (r1125), and then applying the suggested fix in #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.

Replying to lukacu:

I can confirm the problem in MU 1.3.3 when the user edits a page with attachments.

I can also confirm this problem with MU 1.3.3, and editing a post that has a link to an attachment (<a> contains rel="attachment).

The problem only occurs after adding an attachment and inserting it using the "link to" page option. This adds code such as: <a href="attachmenturl" rel="attachment wp-att-3" title="deckplans.swf">deckplans.swf</a>

This rel="attachment" causes the _fix_attachment_links() function to be called, after the page is saved, however this function uses an (out of date) cached version of the page. The function then saves the old page content back into the database.

My debugging has shown that wp_update_post() saves the post's new content correctly to the database.

This function then attempts to clear the page cache (calling wp_cache_delete()), which tries to remove $wp_object_cache->cache[20-pages-9], however there is nothing in the cache with that key.

The cache actually contains $wp_object_cache->cache[20-20-pages-9] instead. So somehow the page cache is being stored with the page id in there twice, whereas the cache deletion routine tries to delete the cache with key 20-pages-9.

Then _fix_attachment_links() gets called, which uses the (out of date) cached version of the page, which then saves the previous page's content back into the database.

Revision [1201] may very well fix this, at least it does for me. Can you guys svnup and test it please?

Replying to donncha:

Revision [1201] may very well fix this, at least it does for me. Can you guys svnup and test it please?

SVN Up'd to [1201] and it seems to have resolved the issue. Thanks very much.

Were the changes to cache.php in [1201] only to fix this issue, or were other changes made too?

I'm trying to work out if I can copy the cache.php from [1201] to my WPMU 1.3.3 install.

Thanks!

Just to fix this issue.