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