As you may know, W3 Total Cache is pretty awesome when it comes to providing a highly configurable landscape for WordPress caching. W3 Total Cache generates static cache pages for each page that is loaded so they are not being dynamically loaded for every page load. This vastly decreases your site's load time while increasing performance.
If you are a W3 Total Cache user, or plan to become one to take advantage of how it can boost your site’s performance, be aware that you may come across a 500 Internal Server error. Of course there could be more than one reason why you’re running into a 500 Internal Server error. However, we’ve outlined how to diagnose, and more importantly how to fix, a common W3 Total Cache error experienced by WordPress users below. You should be able to quickly diagnose whether this is the cause of the 500 Internal Server Error that you’re experiencing.
The first thing you will want to do is check your .htaccess file to see if W3 Total Cache has added its .htaccess rules to the end of an existing line. So for example, it may end up looking like this:
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
BEGIN W3TC Browser Cache
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html
BrowserMatch bMSI[E] !no-gzip !gzip-only-text/html
Notice the part that says:
</IfModule># BEGIN W3TC Browser Cache
This is actually what is causing the issue. The "# BEGIN W3TC Browser Cache" should be on it's own line. The solution? Just line break that (just hit enter before the #), save the file and reload the page.
But why did this happen in the first place?
Normal WordPress installations, with Softaculous or a manual install, will create the .htaccess file with the WordPress rewrite code looking like this:
BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
END WordPress
W3 Total Cache apparently looks for the first comment ( # BEGIN WordPress ) so it knows to add its rules before that. However, if the .htaccess files has been modified with the removal of those lines (that line in particular), W3 Total Cache doesn’t know what to do. W3 Total Cache appends its rules onto the last existing line. If you have the # END WordPress line there, it’s no big deal, W3 Total Cache will just add the comment against the WordPress comment and won’t impact Apache.
The problem occurs if there is no comment and no line break. Apache will fail and cause a 500 error because W3 Total Cache will append to whatever the last line is.
Are you using WordPress Multisite? Please be aware that WordPress Multisite’s rewrite code does not include these comment lines at all like the standard install does. That means W3 Total Cache on a Multisite install will very likely break. However if you add the comments as outlined above (really only the BEGIN comment is needed), your install should perform just fine.
