Hummingbird gzip & browser cache won't activate.

Our company is in the process of changing hosting providers. I am testing the target site before we change the DNS settings this weekend.

Normally Hummingbird works fine, and on the production site, it is working completely normal. On the new host, gzip and browser caching are not working and cannot be activated.

We contacted our webhost who responded with:

Thanks for the credentials, I spent some time reviewing the plugin and looking at some of the things it's trying to test and trigger. Looks like it's attempting to use mod_filter to invoke the functionality of mod_deflate. Why I'm not sure. Seems it would be simpler to set it up as mod_deflate but I'm no developer. Which brings me to my next point.

The plugin doesn't seem to be recognizing the mod_deflate is installed though I've given it the proper path by taking out the improper paths. I would suggest reaching out to the hummingbird plugin to see if they know of any workarounds for this specific issue.

On the gzip page it also says it can't detect the status because Privacy mode is enabled and says to disable that, but where/how do we disable privacy mode?

  • Adam Czajczyk
    • Support Gorilla

    Hello Brandon

    I hope you're well today!

    The Hummingbird, if running on Apache powered site, is using mod_deflate. The mod_filter reference that was mentioned in that message - this is related to a part of the code that plugin adds to the .htaccess that is supposed to "select" specific MIME types to be processed through "deflate".

    It's worth mentioning though that if, for example, mod_filter module is not availalbe or not working on a server that set of rules would be ignored and compression should still be applied (only that there might in some cases be a different set of MIME types gzipped depending on Apache configuration on the server).

    However, there's a different aspect here that seems important. Both production and testing sites are on the same server, correct? But the testing site is not "publicly available" via its domain (for example, I would have to add an entry to my hosts file to be able to load correct site).

    The cache/gzip check does check rules in .htaccess/nginx conf file but also queries the site so if it either cannot access it or it's actually accessing a wrong site (due to DNS pointing the domain to a different location) that will not bring back right check. It's a bit uncommon scenario in that sense that it's perfectly fine to create test site and use domain this way but since you can't add such entry (like the one added to hosts file) to The Hub/our API and for some plugins/services to work the site has to be available (API connection must work two ways) it might result in false alarms.

    To sum it up: if both live and test sites are on the very same server, I believe it's a "false alarm". The "privacy mode" warning basically tells what's happening: we are unable to correctly detect gzip/cache. If I may suggest something, I would actually assume that it is working but just can't be checked and after the DNS is changed I'd clear transient (some check data are also stored in transient cache in db) - that can be done e.g. using Hummingbird's "Database cleanup" - and re-check gzip/caching again. If that still doesn't work that would rather suggest some issues with the site itself but we'd be able to run proper checks on it then.

    Kind regards
    Adam

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.