Rewrite / Disk Cache-enhanced / Minify not working in W3 Total Cache : Idiotproof checklist

W3 Total Cache is hands down the best speed solution I have ever found for WordPress. However, it can be a little intimidating to configure, and sometimes gets you stuck. Being a self-learned admin, I am more often the idiot, so I go back to what works and figure it out. Here’s my bombproof checklist that has never failed

If you get something like this:

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.

It appears Minify 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.

Most of the standard advice is not too useful. Then there are those who simply call it a W3TC bug and leave it at that. Maybe it was a bug earlier, but I guarantee you it is working right now and that you can make it work. *

[* = Minify in W3 Total Cache needs php5.5 to work. Most people seem to have php5.3 – then it won’t work and this guide can’t help you – you will have to upgrade php if it is that crucial for it to work.]

Of course you could turn off minify and disk-caching:enhanced in W3 Total Cache and the problem will be gone, but if you want to *make* it work, for the functionality or because you may be like me and something not working drives you nuts… read on.

Check installed modules: env, rewrite, mime, headers [if you can fix this, you might as well go ahead and make sure expires is active too for better caching]. On a debian/ubuntuinstall, you’d do
```
a2enmod env
```
for example.
No rocket science needed here, but I’ve once scratched my head for an hour and tormented myself with checking htaccess files and permissions and what not on a new debian install only to realize mod_env was not active.
Check your .htaccess files. Yes. In the plural. The .htaccess in the root directory should contain W3 Total Cache rules *before* the WordPress rules. Then, there would be more .htaccess files depending on what you have enabled. For example, if you have disk enhanced caching enabled, you’d have an .htaccess to check in the pgcache folder inside w3tc folder inside your wp-content directory. Which brings me to…
Check the w3tc folder. I cannot stress this enough. If you want your page caching to work, your wp-content folder will have a folder called w3tc, which will contain a folder called pgcache [if you are using minify, there will be a folder called “min” too]. If it isn’t there, create it. If it is there, chmod its permissions to 777. It should contain an .htaccess file. If the file isn’t there, or you had to create the folder, go to your admin panel for W3 Total cache, click the tab for “Install” scroll down. You will have .htaccess rules applicable for your site listed there. Copy the correct ones – the file paths are written above the content. Can’t go wrong.
Go up to your wp-content directory and make sure to chmod your file/folder permissions to 777 – once you get page cache working, you could lower them to find the minimum required. First let’s get it working.
Check for crucial files. You can’t miss this. There will be a red alert on your admin panel if files are missing – usually complaining that your wp-content folder is not writeable or the files are missing. See named files, make sure they are there. If they aren’t, you could download a copy of the plugin to grab them easy.
I have never failed to get W3TC working with all this right. Yes, I am talking “disk:enhanced” page caching. But as a last shot, worth checking for file ownership, particularly if, like me you are in the habit of ssh-ing in as admin on the server to edit files. If you have entered the WordPress directory, it is worth setting the correct ownership when done to save yourself a lot of misery later.

Note: If you have renamed your .htaccess, you may want to copy back any customized rules that you may have put into it from the old file to the new file. Be ready to take them out if they cause things to crash again 😉

Posted

February 7, 2012

Ubuntu Server Configuration

Vidyut

Tags:

.htaccess, permissions, w3tc

Comments

14 responses to “Rewrite / Disk Cache-enhanced / Minify not working in W3 Total Cache : Idiotproof checklist”

Andrew McConville
March 9, 2012
Nice post/guide.
I’m using a VPS with LiteSpeed, cPanel and APC; I wanted to install W3TC but…
Upon activation I get the error that /wp-content needs to be chmod 777, so I do that.
Next error is to add define(‘WP_CACHE’, true); to config.php, so I do that.
Now the plugin is activated but I get an error that .htaccess needs to be chmod 777, I do that, but W3TC never writes to it, even after clicking auto-install. So I manually copy and past the code into .htaccess and the error still comes up that the code is missing.
I’ve created 3 different cPanel accounts with clean WordPress installs and W3TC always gives me the same errors.
Any tips would be helpful.
Reply
1. vidyut
  March 9, 2012
  I have something for you to try. I don’t know why it is so, but I encountered this too. Go and save permalinks and then try again in W3TC. That worked for me. When that failed, deleting .htaccess, saving permalinks again, then W3TC worked. Don’t know why that happens.
  BTW, it has nothing to do with the CHMOD 777. No clue why it instructs for that, but normal permissions shouldn’t hinder server, wordpress or W3TC from writing.
  Reply
  1. Andrew McConville
    March 9, 2012
    Thanks for the help, I removed my .htaccess file and then saved the permalinks, wordpress put it’s code back in, but clicking auto-install in W3TC did no put any code in .htaccess.
    The W3TC compatibility check says /.htaccess: Not write-able, if that helps.
    Reply
    1. vidyut
      March 9, 2012
      If your page caching is set to disk enhanced, try changing it to disk basic – does that help? This is a particularly bothersome situation with W3TC, but once it works, it brings joy…
      Reply
    2. vidyut
      March 9, 2012
      I don’t have a “right answer” – sharing all I tried – whichever of it worked, W3TC is working for me right now.
      Reply
      1. Andrew McConville
        March 9, 2012
        My page cache method is Opcode.
        Thanks you for the tips, one more thing I can point out is that In the W3TC compatibility check I see that W3TC is looking to write to /.htaccess
        shouldn’t it be directed to:
        /home/andrew6/public_html/.htaccess
        W3TC compatibility text:
        /.htaccess: Not write-able
        /home/andrewm6/public_html/wp-content: OK
        /home/andrewm6/public_html/wp-content/uploads/2012/03: OK
      2. vidyut
        March 9, 2012
        That is correct. The path should be (as you said) /home/andrew6/public_html/.htaccess That is how it is for me. Don’t know if it was wrong when I was having problems.
        By any chance, is your wordpress migrated? Perhaps the old path has been stored somewhere? Try going to main settings page (with wordpress address) and simply saving that page again? *shot in the dark*
        Hmm… so naturally it can’t write. Will need to see what could cause the path being incorrect.
  2. Jesus
    May 5, 2012
    Vidyut, the solution to the problem is to change the order in which some of the .htaccess rules are stored, that way, there is no need to revert to ‘disk’ and Disk advanced can be used without problems. Simply make sure that the ‘default’ .htaccess rules you add when installing wordpress fresh are position as the last block in your .htaccess file.
    Reply
    1. Vidyut
      October 13, 2012
      Yes. You are right. It wasn’t clear in how I wrote. WordPress rules must come after the W3TC rules in the .htaccess in the root folder. I have now updated the post with more accurate instructions including making this clear. Thank you.
      Reply
Marc Daly
May 24, 2012
When I used the Auto-install option for the Page Cache code, it was always added AFTER the wordpress directives. I deleted it, then manually added it BEFORE the wordpress section, and the error message disappeared.
Reply
1. Vidyut
  October 13, 2012
  Yes, I had this problem too. I had to manually edit the .htaccess files. However, this now seems to be working correctly (prepending the W3TC rules instead of appending) in the new version of the plugin.
  Reply
Koltuk
June 17, 2012
thanks a lot.
Reply
Manuel Razzari (@mrazzari)
December 17, 2012
I tripped up on this for my dev server due to a hosts file issue.
The way this error message is triggered on W3TC, is by trying to HTTP GET this file, which should return “OK”: http://example.com/w3tc_rewrite_test
If you are pointing to example.com via your hosts file (as is common in dev), then of course your server will not be able to resolve the domain, unless it also has a hosts file of its own. The request will 404, and the error will be displayed, even though enhanced page caching will be fully working.
Reply
Julien Desrosiers
January 28, 2013
I noticed that “http_request_timeout” can also be the cause of this error if your site or your server is slow.
You can try adding this to your functions.php so that the http request timeout is longer:
function my_http_request_timeout($timeout_seconds) {
return 30; // instead of the default WP_Http 5 seconds
}
add_filter(‘http_request_timeout’, ‘my_http_request_timeout’);
Reply