Getting Gargled Text In Internet Explorer 7.0

This happens when compression is enabled.

Is this the gzip compression enabled in WP control panel? (options->reading.)

regular compression

And this is?

[…]this plugin

And what plugin is this?

Try to explain your setup a little better, makes it easier for others to help that way ??

I’m guessing it’s the WP Super Cache plugin from the tag ??

bazil – are you using the latest 0.3.1 version? Is the garbage showing when you’re logged in or when viewing your site as an anonymous user?

Yep, the latest 0.3.1.

Um, WordPress compression is off as the document needed (doesn’t the plugin turn it off anyways?).

And it happens when I’m anonymous. As I understand, logged in users don’t get pages that are super cached right?

The funny thing is that it happens sometimes. I haven’t done much testing on it (everything was live when installing).

Or it could be my host. Would I need some addition stuff in my .htaccess this maybe:
AddEncoding x-gzip .gz .tgz
??

Regardless, EXCELLENT PLUGIN MAN!

My solution:

<Location /wp-content/cache/supercache/>
AddEncoding x-gzip .gz
AddType text/html .gz
</Location>

The complete post:
https://allmybrain.com/2007/11/08/making-wp-super-cache-gzip-compression-work/

Man, I was having exactly the same problem. Your fix is spot on! Thank you.

This goes in the .htaccess file?

Do I need to provide a full server path?

bazil – I merged Dennis’ changes into trunk so if you go to the download page of the plugin and grab the development version the plugin should create a .htaccess file in your cache directory automatically.
Hopefully that will fix the compression problems, and I’d love to hear if it works for you.

I’m not sure why, but I upgraded to the development version, changed the wp- to wp-.*.php, changed my slug back to the way it was, deleted my cache, and then revisited the pages and the cache was not regenerated for those pages. I switched back to 0.3.1 for the time being. I’ve got another blog I can test changes on a little easier if needed.

Edit: This did actually work on another blog I’m testing so the development version seems to be pretty solid.

-Dennis

A side note, I’m not sure if I needed to enable or disable the plugin for any changes to take effect. That my have been my problem but I didn’t get a .htaccess file automatically created either.

Edit: I was looking in the supercache directory and the .htaccess is in the cache directory.

-Dennis

mulicheng – thank you for testing! It’s strange that the reject regex worked on one blog and not the other!

Actually, after I went back and tried it again, it worked. I may have done something to invalidate the cache without recreating it the first time.. like posting a comment or something. I noticed that editing articles deletes the cache (as it should) and I may have not realized that I deleted it. That’s just a hypothesis though. Either way, it is working just fine now.

Thanks
-Dennis

Hey Donncha:

I noticed that after a period of time, the .htaccess file was missing in /wp-content/cache

I’m wondering if the plugin deleted it as part of a cache cleanup or something.

Edit: I just confirmed this on my test blog. After a period of no activity, I check the cache directory:

>ls -la
total 32
drwxr-xr-x 4 apache apache 4096 Nov  9 09:46 .
drwxrwxr-x 5 root   apache 4096 Nov  8 09:57 ..
-rw-r--r-- 1 apache apache   81 Nov  9 09:40 .htaccess
drwxr-xr-x 2 apache apache 4096 Nov  9 14:03 meta
--snipped wp-cached content files--

Now, the directory listing after I request the home page:

>ls -la
total 20
drwxr-xr-x 4 apache apache 4096 Nov  9 14:03 .
drwxrwxr-x 5 root   apache 4096 Nov  8 09:57 ..
drwxr-xr-x 2 apache apache 4096 Nov  9 14:03 meta
--snipped content files--

The .htaccess is indeed being removed.

Thanks Dennis – I was afraid of that. I even tested for it by deleting the cache from the backend but the .htaccess seemed to survive. I should have realised that the backend admin page would have recreated it.

That explains some problems other people have had with gzip compression. *Thank you!*

Just checked in a change to hopefully fix this.

I repeated my tests from the backend admin page and the .htaccess file wasn’t deleted because I error_logged all delete operations. Maybe your operating env is slightly different enough to make a difference to that.

I grabbed the latest dev version this morning and tested it out. It seems to be working correctly now and does not remove the .htaccess file.

Thanks
-Dennis