W3 Total Cache 1.0? – Sneak Peek!

Banner of W3 Total Cache pluginUpdate (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

Screenshot of email from FrederickWhile 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…

Technical info from W3 Total Cache plugin

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…

W3 Total Cache plugin screenshot - purge from admin menu bar
Directly purge individual cache from admin bar
W3 Total Cache plugin - screenshot showing options to purge individual modules
Purge individual modules

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…

W3 Total Cache plugin - Screenshot of menus under 'General Settings'
General Settings
W3 Total Cache plugin - Screenshot of options showing cache control for various users.
Cache control for various users
W3 Total Cache plugin - Screenshot of Purge policy
Purge policy – Now with more options
W3 Total Cache plugin - Screenshot of options under JS minify
The most awaited feature!
W3 Total Cache plugin - Screenshot of cache control policy for static content
The default cache control policy for static content. You may choose differently, though!
W3 Total Cache plugin - Screenshot of FAQ section
More info in the FAQ section. Do you read it?

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!

5 Replies to “W3 Total Cache 1.0? – Sneak Peek!”

    1. The CDN menu has two new options…

      • Enable mirroring of pages – Enabling this option allows the CDN to handle requests for unauthenticated pages thereby reducing the traffic load on the origin server(s).
      • Add canonical header – Adds canonical HTTP header to assets files.
  1. Pothi,
    “…Add canonical header – Adds canonical HTTP header to assets files …”
    So what does this mean/do ? How & when to use it?

    Thanks

  2. 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).

Leave a Reply

Your email address will not be published. We use cookies to prevent spam comments. Required fields are marked *

css.php