Leirith

Ah great. Thank you, that worked nicely.

Thank you. I’ll deactivate those two to start with, see if that helps and post an update.

Unfortunately disabling Google News Sitemap doesn’t seem to have helped. Here’s a list of currently active plugins.

• Akismet
• Easy Disable Visual Editor
• Facebook OpenGraph
• Legacy Permalinks
• Role Manager
• Topsy Retweet Button
• WP No Category Base
• WP Super Cache
• WPtouch Pro
• You Can Javascript

The problem query is

SELECT SQL_CALC_FOUND_ROWS  wp_posts.* FROM wp_posts  WHERE 1=1  AND ( wp_posts.ID IN (
					SELECT object_id
					FROM wp_term_relationships
					WHERE term_taxonomy_id IN (146)
					GROUP BY object_id HAVING COUNT(object_id) = 1
				) ) AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 10;

Could anyone offer tips on identifying the source?

Thanks very much for the reply! I’m currently considering a plugin that creates sitemaps for Google search as a possible culprit (Google News Sitemap). I suspect it’s reading the whole posts table and locking everything else out.

You mentioned it was occurring when saving posts, which is probably the hook that the plugin would use to do its work.

Hi user, I’m currently experiencing the same issue after upgrading from 3.1 to 3.1.1. Were you able to resolve it? If so what did you do? Thanks!

If anyone else has any ideas, I’d very much appreciate your assistance.

I have noted that when the database is unavailable, there are a large number of MySQL processes in the “Locked” state. These processes are performing queries related to the WordPress database. What could cause so many processes to become “Locked”?

Thank you for your reply.

The database settings are okay – the problem is intermittent, so the connection is usually successful.

I’ve been running a diagnostic loop in PHP where I establish and then close a connection every second. It failed once with a “Too many connections error” which could be the cause of the problem.

Hi Pete,

Yes, create the PHP file in the wp-content/plugins/wp-super-cache/plugins folder with the code I posted. You can call the file anything you like.

Don’t worry about it not showing up in the admin screen – it will still execute. I’m not sure how to add it to the admin screen actually. I can see there is a file that lists the other plugins but I haven’t found any documentation for how to modify it. Perhaps it’s something that donncha can clarify.

I also added a filter for the rewrite rules as suggested by donncha. This code went in the same file.

function fbconnect_patch_supercacherewriteconditions($condition_rules) {
    $condition_rules[] = "RewriteCond %{HTTP:Cookie} !^.*fbs_.*$";
    return $condition_rules;
}

function fbconnect_patch_filters() {
    add_filter('supercacherewriteconditions', 'fbconnect_patch_supercacherewriteconditions');
}

add_cacheaction( 'add_cacheaction', 'fbconnect_patch_filters' );

Hope this helps.

There is an error in the code for the theme you are using. If you look at the file named in the error, it is trying to call a function called num_pages(), but the variable on which it’s being called isn’t initialized.

Sorry everyone, I have figured it out! I thought I’d removed an incompatible plugin “Top Level Categories” but it was still installed. Very frustrating to find that was the cause as I’d already been through that once already with another installation.

Here’s the code for the plugin.

<?php

function fbconnect_patch_get_cookies_values($string) {
	if (!isset($string))
		$string = '';
	while ($key = key($_COOKIE)) {
		if ( preg_match( "/^fbs_/", $key ) ) {
			if ( isset( $GLOBALS[ 'wp_super_cache_debug' ] ) && $GLOBALS[ 'wp_super_cache_debug' ] ) wp_cache_debug( "Cookie detected: $key", 5 );
			$string .= $_COOKIE[ $key ] . ",";
		}
		next($_COOKIE);
	}
	reset($_COOKIE);

	return $string;
}
add_cacheaction('wp_cache_get_cookies_values', 'fbconnect_patch_get_cookies_values');

?>

Below is the line that I altered in .htaccess. It occurs twice in this file. As you can see I added the cookie prefix “fbs_” to the regular expression.

RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_|fbs_).*$

Hi dspilka,

Initially I suspected the issue was purely related to the facebook plugin, but I then noticed the issue was reproducible for specific URLs on the site. I thought about how pages were being cached by WP Super Cache and discovered that the logged in view was being cached by WP Super Cache by searching in the supercache directory for files containing strings from the logged in view.

I then wondered if the issue was related purely to WP Super Cache but I made a test installation without the facebook plugin and the issue wasn’t occurring – so I installed the facebook plugin and the issue was back.

I set about looking at how WP Super Cache was determining whether or not a user was logged in and found the function in wp-cache-phase1.php, there is a function called wp_cache_get_cookies_values(). It looks for three different cookie keys that WordPress sets when a user is logged in. I stepped through the code and found that when a user was logging in with facebook, those cookies were not being set right away. There was however a cookie that was being set at this stage, which was of the form fbs_<facebookAppID>.

I found an article that described similar issues with a facebook plugin and WP Super Cache, and in that case it was solved by writing a plugin for WP Super Cache to check for an additional cookie key. The cookie key was different to the one my facebook plugin was setting, so I adapted the code from wp_cache_get_cookies_values() in wp-cache-phase1.php, added it to a plugin which hooks to wp_cache_get_cookies_values and placed it in the WP Super Cache plugins directory. Additionally, as a comment in wp_cache_get_cookies_values() suggested, I added the cookie to test for to the conditions in the .htaccess file in the WordPress root directory.

I’ve finished writing and testing the WP Super Cache plugin. So far over 3000 pages have been cached on the production sites and none of them show the logged in view, which is good news. The cookie to test for was of the form “fbc_<facebookAppID>” and I used the wp_cache_get_cookies_values hook to add it.

Thank you for your response.

I think it’s something to do with the Facebook Connect plugin that’s installed. It may not be setting the required cookies at the appropriate time when it handles logins. Their support isn’t as great – they’re not even on www.ads-software.com, but I’ve seen some user suggestions to use a WP Super Cache hook to set add cookies to be checked. I’ve been working on something to that effect since reading those comments. Apparently it’s a common problem so hopefully I can work it out. In your experience are there any alternatives that are known to work with WP Super Cache?

I checked the WP Super Cache log at the time when one of the files was created.

10:53:40 /2010/01/<article-slug>/ Output buffer callback
10:53:40 /2010/01/<article-slug>/ Anonymous user detected. Only creating Supercache file.

The problem is that the user wasn’t anonymous. What could be going wrong?