schirpich

Sounds like a problem in varnish. Have you checked to see that a .gz file is being produced to varnish. What does apache’s log say in the access.log when you try to reproduce this with a fresh cache all around?

But let me ask you this, if you are using Varnish, why are you using both nginx and apache? You could have Varnish caching and serving nearly all of your static content even though it’s “originally” coming from Apache (or nginx if you choose to ditch apache).

You could simply tell varnish to pass the first image request straight through, which will then cache it with varnish on that first request. Eliminating any further passes to your backend until the next purge. Which you are probably already doing, but you are just running an extra webserver for no real reason. Once you eliminate the either of the webserver’s you’ll save yourself some extra memory and cpu time.

I think you could even manipulate the VCL to store the larger cached items like pictures, zips or whatever to a disk cache file. And a separate sub section to store everything else to malloc with varnish.

bleh,,, I’m just getting ahead of myself here. My point is, either go through each step to make sure a .gz file is being passed along. The logs will tell you this straight up. But I would also suggest you cut either nginx or apache out completely. With Varnish there’s no need for the both of them.

any word on this? I am in search of a similar function.

I’m getting this behavior too. Global Translator is gone, deleted, no more. Yet it still continues to redirect those specific Lang Acronym’s.

Tried clearing the cache, opcode cache, everything. Is this thing leaving traces of itself in the WP php code or something?

I thought the same thing, makes sense. However when you remove the widget I noticed this new little status message popped up in the GT Settings that said,

You haven’t added the flags widget on your pages: adding the flags bar is mandatory in order to make Global Translator able to work correctly

So that was a lost cause. I didn’t notice that little gem for about 3 days.

nevermind the gzip on the CDN thing, I just saw an earlier post in regards to the “_htaccess” file provided in the ini/ directory. Works like a charm

I’ve actually been at it all morning so I’ve been in and out of the site. I’ve actually made some big progress. I think what I’m actually running into are issues with the theme itself.

For instance, I’ve found that once I’ve added all my js files to the default template I CANNOT check the “Comment Removal” or “Line Break Removal” boxes without breaking my tabbed sidebar.

Right now I’m trying to figure out where to add screen.css and print.css. If I add those two files into the default, Firefox renders the images with black borders. Chrome and IE 8 do not. But if I leave those two files out of the default on their own like normal everything seems to be kosher. If I put them into the header template, the black borders appear again. I think I may email the theme developer about that one some more unless you know of what might be the issue there, but I don’t expect that you should.

But there is one thing you can answer for me, I’ve enabled the self hosted CDN on a separate subdomain. However Firebug shows no gzip compression for anything hosted on the self hosted CDN. even though gzip is enabled within wp-admin/w3tc settings and all pages coming from the normal site are gzip’d. I have an idea that it might be permission related considering I’m using two different users for the apache process.