Update (Feb 5, 2013): The beta version that I tested, has been released as version 0.9.2.6 with more features than mentioned below. So, this post is void as of February 5, 2013 (in less than 2 weeks of publishing it). :(-
W3 Total Cache is back in active development, nearly after a year. I’m one of the lucky people who got the opportunity to test the beta version of the upcoming release, probably 1.0.0.0! It brings a few new features, including a more-intuitive troubleshooter.
An Email from Frederick
While I was actively volunteering in WordPress.org support forums, once I noticed a message from Frederick to email him to get an opportunity to test drive the next version his invaluable work, W3 Total Cache plugin for WordPress. I received the beta version last month (year?), after a very long wait. Unfortunately, I was too busy to try out the next version, after the initial hiccup, in the way he setup the new navigational menu system in the beta version. Actually, I like it now, after understanding how it really works.
The in-famous “Page Cache URL rewriting is not working” Error
Recently, I transferred a site from a managed WP host to a dedicated server where I was asked to install W3 Total Cache plugin. I did install and activated it. While testing various options, specifically “disk enhanced page caching”, I received the following error…
It appears Page Cache URL rewriting is not working. If using apache, verify that the server configuration allows .htaccess or if using nginx verify all configuration files are included in the configuration
If you’ve used W3 Total Cache in multiple web hosts, I guess you may know what that error means. I was not surprised with that error, because I’ve fixed this error in the past on servers running on Nginx as well as on servers running the rock-solid general purpose web server, Apache. So, I checked the permissions, rewrite rules and did everything I can. I was running short of time and became impatient. :)
Finally, decided to install the beta version of W3TC. Once installed, it showed the same error with a minor difference that actually made a major difference in the end. Here is how the error looks like in the beta version…
Can you spot the difference? I bet. There is a link entitled “Technical Info”. Upon clicking on the link , Frederick showed more information that goes like this…
nginx configuration file contains rules to rewrite url http://domainname.com/w3tc_rewrite_test into http://domainname.com/?w3tc_rewrite_test which, if handled by plugin, return "OK" message. The plugin made a request to http://domainname.com/w3tc_rewrite_test but received: 404 Not Found instead of "OK" response. Unfortunately disk enhanced page caching will not function without custom rewrite rules. Please ask your server administrator for assistance. Also refer to the install page for the rules for your server.
I replaced the actual domain name in the above error message. This “technical info” provided me a clue on what went wrong. I was accessing the dedicated server using “hosts file hack“. The DNS was still not changed and was still pointing to the managed WP host that didn’t use W3 Total Cache plugin. Naturally, after the DNS change, everything worked as earlier. :) I can’t thank Frederick enough for providing the beta version and the “technical info” on the error.
Screenshots
Since the above incident, I started exploring the other hidden details in the newer beta version of W3 Total Cache plugin. Here are the screenshots for you, with my (tiny) comments in the caption…
The following screenshot may need some explanation for someone who never used the left-side menu to navigate through the various options in W3 Total Cache plugin. Clinking on the individual items in the beta version will not take us through the detailed settings page that is now accessible only via the left-side menu for W3TC in WordPress dashboard. So, don’t be surprised, if you don’t find the link to Install section in the following screenshot…
What’s next in W3 Total Cache?
I haven’t explored all the options available in W3TC. I’ll continue to dig further and will post more details, as I see fit. In my opinion, the major changes are…
- Better support for Nginx and Varnish.
- More purging options – for sites with thousands of posts, these options may become a life-saver. It offers the ability to fine-tune what can be purged, instead of purging everything in the site. A lot of CPU cycles and memory can be saved.
- Finally, I’m really excited to see JS defer parsing.
Not sure, what else Frederick has in mind to bring into the next major version of his plugin that is still the de-facto standard for performance tuning for thousands of sites. It could be CSS sprites!
Hi, great post. Curious what updates the CDN menu received ?
The CDN menu has two new options…
Pothi,
“…Add canonical header – Adds canonical HTTP header to assets files …”
So what does this mean/do ? How & when to use it?
Thanks
Great question Conrad.
While I haven’t tested it, here is a little explanation on mod_pagespeed documentation. While both are different, that link should provide a clue on what could be done on certain files, especially JavaScript files that may have been hosted by Google and others.
I hope that helps.
Thank you,
Pothi
Found that 0.9.2.6 and upto 0.9.2.11 actually perform noticeably slower, so rolled back to 0.9.2.5
Also had issues with minified JS and CSS not being propagated to CDN (Generic Cloud) after updates to the code and served old minify cache due to the same file name (this was fixed in later versions though).