For you .htaccess experts...

Bonesnap

Trying to fix a client's website. It's WordPress (inb4hatred). Without going through the actual problem, I discovered this .htaccess file buried among the file structure. I have some knowledge of .htacess, but this is way beyond me. Just wondering if someone would be able to tell me what this means.

# BEGIN W3TC Page Cache cache
Options -MultiViews
<Files ~ "\.(html|html_gzip|xml|xml_gzip)$">
  Allow from all
</Files>
FileETag None
AddDefaultCharset UTF-8
<IfModule mod_mime.c>
    AddType text/html .html_gzip
    AddEncoding gzip .html_gzip
    AddType text/xml .xml_gzip
    AddEncoding gzip .xml_gzip
</IfModule>
<IfModule mod_deflate.c>
    SetEnvIfNoCase Request_URI \.html_gzip$ no-gzip
    SetEnvIfNoCase Request_URI \.xml_gzip$ no-gzip
</IfModule>
<IfModule mod_headers.c>
    Header set X-Pingback "http://[WEBSITEOBSCURED]/xmlrpc.php"
    Header set Vary "Accept-Encoding, Cookie"
</IfModule>
# END W3TC Page Cache cache

I did find a lot of *.html_gzip files in very suspect folders, so that's why I am wondering about this.

Thanks guys!

bradgrafelman

I'm a bit confused by it as well. It's basically inventing new HTML and XML file extensions ("html_gzip" and "xml_gzip", respectively)... but then it's setting the "no-gzip" variable for those extensions. If the intent is to not gzip compress those files... seems like "html_nogzip" and "xml_nogzip" would be more apt names to pick.

Weedpacket

bradgrafemlan wrote:
If the intent is to not gzip compress those files...

Perhaps the "no-gzip" files have already been gzipped and whoever put this together didn't want the server (via mod_gzip or the specified mod_deflate) to waste time zipping them again for transport; presumably reasoning that it would save time to pre-zip those files rather than do it on the fly when they're served - because that is clearly a massive time sink. (Another possible reason for the pre-zipping might be to save space; but a compressed filesystem would achieve the same effect and do so transparently. But that clearly isn't a concern to whoever put this together - these internal machinations mean changes not just for the developer but for the client making a request.)

This of course assumes that all clients making requests will "Accept-encoding:gzip"; responses to clients that won't will be broken.

And needless to say, if these extra considerations are going to be imposed on users of this w3tc cache or whatever it's called, it would be nice if some documentation were to be provided that justifies them. (Edit: Ah, A Google search on the product name suggests there is).

Fair warning: I'm not an .htaccess expert either.

dalecosp

Nor am I ... this is apparently part of an older implementation of the W3 Total Cache plugin for WP.

The newer .htaccess for this plugin may be on [url-http://wordpress.org/support/topic/w3-total-cache-error-files-and-directories-could-not-be-automatically-created-t?replies=16]this page[/url] and looks a bit more normal....

Bonesnap

Thanks for the replies guys! The good news is this client is a server admin so they know tech stuff AND they keep image backups of their stuff, so I am waiting for a backup before their problem started occurring so I can compare files. Basically the issue is when a page is viewed for the first time, a database connection error is shown (it's a WordPress error, not a PHP error); however, when you refresh the page, it loads just fine. If you click off the page to another one, same thing, then you hit refresh and it's okay. I'm thinking it has something to do with caching plugins or something with a cache. It just comes at an interesting time because I made an addition to their site to add a shortcode for him, so he just wants to make sure it wasn't something I did, but I don't see how that would affect database connections.

In any case, the copy of the files I have from when the site was experiencing issues has confirmed malware on it (or at least remnants of it) that looks linked to the cache plugin(s), so once I am able to compare the backup files with the problematic files, I can confirm it wasn't me. They are running a very ancient version of WordPress as well which doesn't help anything (and is probably the reason the site has issues).

Once again, thanks for the replies!