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
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!