All Website Pages Downloading GZ File After Latest Update

@yet Another WP User

I’ve always used this code instead of WPSC’s option to compress and have had no problems whatsoever. You can test by inserting the code manually and testing via https://checkgzipcompression.com/

Yep, using mod-rewrite with compression on dozens of sites on my server that I’ve held off upgrading to the latest SC version. On a new site on the same server, compression check results in a file download rather than a page display, whereas it’s always worked before. My server will auto-gzip anyway, but it was nice to have a cached gz file ready.

Does it work same as Wp Super Cache’s compression option?

I don’t think that this will produce gzip’ed precache files. It’ll rather gzip on each request.

I can be wrong though…

I can confirm this bug. It is happening because when using mod_rewrite with gzip compression, the “wp-content/cache/.htaccess” file does not properly contain the magic gzip stuff anymore:

# BEGIN supercache
<IfModule mod_mime.c>
  <FilesMatch "\.html\.gz$">
    ForceType text/html
    FileETag None
  </FilesMatch>
  AddEncoding gzip .gz
  AddType text/html .gz
 ....

Instead, it contains ONLY this:

# BEGIN INDEX
Options -Indexes
# END INDEX

It appears that somehow, the new code that creates the index protection makes it not correctly write the “supercache” section. I can easily duplicate this by simply re-saving the settings.

Donncha, perhaps this is enough for you to troubleshoot it; if not, I’ll try to trace what code path makes this happen later today.

I tracked this down. The bug is in line 1454 of “wp-cache.php”:

if( !is_file( $cache_path . '.htaccess' ) ) {
    $gziprules = insert_with_markers( $cache_path . '.htaccess', 'supercache'...

This says “if the file at /wp-content/cache/.htaccess doesn’t exist, create one that contains the gzip rules”.

That always worked before version 1.4.5, because nothing else creates that file. But in 1.4.5, the file has already been created by function wp_cache_add_index_protection(), so the line 1454 test now fails to add the necessary gzip rules.

I think the if( !is_file at line 1454 should probably just be removed completely, making it run insert_with_markers whether the .htaccess file already exists or not.

(This should probably be a high-priority fix released ASAP; the bug breaks most WP Super Cache sites where people turn on gzip compression.)

Finally someone was able to reproduce the bug and track down the reason behind this annoying problem.

Thanks tigertech to your awesome work. I hope the plug-in developer will fix the issue very soon and release the new update. ??

Thanks for the fix. Copied the “magic sauce” from another site. Of course I can’t change the settings without it overwriting the .htaccess file again.

I can confirm the bug and that tigertech’s fix works as well.

After setting all my settings the way I wanted them, I added this just below # BEGIN WPSuperCache in my .htaccess file:

<IfModule mod_mime.c>
<FilesMatch “\.html\.gz$”>
ForceType text/html
FileETag None
</FilesMatch>
AddEncoding gzip .gz
AddType text/html .gz
</IfModule>

That fixed it.

I wonder why the plug-in author is not replying to this thread and why not he is trying to release an update to fix the issue as so many people are facing this bug.

Thanks Tigertech. Until a new release is made please use PHP mode to serve cached files, but we’ll get it fixed in the next few hours.

^^ I appreciate it a lot. Thanks. I’ll eagerly wait for the next release. ??

@donncha O Caoimh
When are you going to release the new version? Its been 2 days already. Please release the fix soon. Thanks.

Yet Another WP User:

I’m sure Donncha will get to it when he can, but it’s unrealistic to expect him to fix it immediately when he doesn’t even get paid to do this work.

Have you tried applying the fix yourself based upon what we wrote above? It’s not hard to do, and it should hold until Donncha creates his update.

All you need is FTP access to your website or a WP plugin that allows you to edit the .htaccess file, such as the Yoast SEO plugin by the Yoast Team (go to SEO > Tools after installing the plugin and scroll down).

Well Donncha did say it would be fixed within a few hours 2 days ago, so…..

Okay, sure, so he missed his own deadline. We already know how to fix it on our own installations, so why complain about Donncha?

If it were a bug that none of us knew the solution to, that would be another thing entirely. But that’s not the situation, is it?

I’m sure he’ll get it fixed soon enough. Meanwhile, we don’t have to suffer.