Last updated on November 20th, 2015
I’ve finally sorted out why I couldn’t get WP Super Cache working…
For those that don’t know, the WordPress plugin is designed to deliver straight html pages to the client browser, zipped if the host will do it. This makes page loads a lot quicker for the user – which is good! Normally, all pages are dynamically created on the fly for each client visit. The database driven method of page generation is good for maintenance, but is a bit slow for the user, so I was interested in increasing usability, naturally.
Previously, I’d tried the thing and always gave up. This time I battled through and the answer was right at the very bottom of the FAQs!
The key, for me, was to look at the page source, and right at the bottom I found:
<!– Page not cached by WP Super Cache. Could not get mutex lock. –>
Whacking this into a popular search engine led me to the bottom of the plugin’s FAQs, here, which is item 13 (unlucky for some) but isn’t explicitly defined. All I did was to look for the line:
“$useflock = true” in wp-content/wp-cache-config.php
Unfortunately, the syntax/wording is slightly different in the latest version. But the principal is the same. This is the current line:
$use_flock = true; // Set it true or false if you know what to use
I uncommented and left it at true, as it worked, which is all I was after. Now I’ve started implementation on some of my more popular sites. They seem to be a bit snippier and zipping is working on my (cheap) host. This was especially important on Crawling Chaos because of the media files that also have to be delivered concurrently with my verbose content.