Webdesign code and practices collection

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.

or

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 😉

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.

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.

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

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.

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.

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.

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.

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.

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.