[Hummingbird] Gzip Compression on HTML type disabled after recent update

Just noticed that after the recent update, 2 of the websites having issue with the Gzip compression on html type (I haven't check the others but will do after this). It is disabled even after you manually put the code in htaccess and even after rechecking several times - still it won't activate. What else to do to activate this?

  • Nahid

    Hey gagabytes !
    Hope you are having a great day!

    I'm sorry to hear about the issue that you encountered. I tried to replicate the issue on our test sites with the latest version of the plugin but couldn't. Gzip compression is working as expected on my end. Here's a screenshot for reference:

    This seems to be an issue specific to your sites. If you have ensured that the "mod_deflate" module is enabled in Apache and the htaccess rules are correctly placed in the .htaccess file, could you please go through the following troubleshooting tests which'd help us determine the source of the issue?

    1. Plugin/theme conflict test: Try running a full plugin/theme conflict test just to make sure no other plugin(s)/the theme on your site is/are conflicting with Hummingbird Pro and thus causing the issue. The basic concept is to temporarily disable all the plugins except Hummingbird Pro (and WPMU DEV Dashboard), switch to a default WordPress theme and check if the issue still persists. If it doesn't, please enable all plugins and the theme one after another to see activating which brings back the issue. This handy flowchart can help you do a full plugin/theme conflict test.

    2. Enable debugging: If the plugin/theme conflict test doesn't help, please enable WP_DEBUG. You can enable debugging by putting the following constants in the wp-config.php file:

    // Enable WP_DEBUG mode
    define( 'WP_DEBUG', true );
    // Enable Debug logging to the /wp-content/debug.log file
    define( 'WP_DEBUG_LOG', true );
    // Disable display of errors and warnings
    define( 'WP_DEBUG_DISPLAY', false );
    @ini_set( 'display_errors', 0 );

    These constants must be added before the line "/* That's all, stop editing! Happy blogging. */" for them to work. Please make sure identical constants are replaced if they were already there previously.

    Enabling debugging in WordPress will log any errors that the site encounters in a log file named "debug.log" located in the "wp-content" folder. Please upload the debug.log file in a cloud storage platform like Dropbox and attach the shared link in your next response so that we can take a look into it. You can know more about WordPress debugging in this handy article.

    Note: It is highly recommended that the site is backed up before the tests or the tests are done in a cloned staging site.

    Hope this helps. We'll be looking forward to hearing from you. Thanks!

    Kind regards,
    Nahid

  • Nahid

    Hey gagabytes !
    Hope you are doing well today!

    Thank you for going through the troubleshooting tests for us. Could you please provide us access to your site so that we could take a more in depth look into this? You can send that privately through our secure contact form: https://premium.wpmudev.org/contact/#i-have-a-different-question

    Send in:

    Subject: "Attn: Nahid Mohit"
    -WordPress admin username
    -WordPress admin password
    -login url
    -FTP credentials (host/username/password)
    -link back to this thread for reference
    -any other relevant urls

    We'll be looking forward to hearing back from you. Thanks!

    Kind regards,
    Nahid

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.