Admin redirect loop caused by Hummingbird

Hi @muchris

Sorry to hear you are having this issue,

Hummingbird will only write in htaccess to add the browser cache or Gzip if both modules are enabled in the plugin, however, those shouldn’t create any redirect.

Could you copy and paste the code that keeps being added after removing the plugin?

Best Regards
Patrick Freitas

Hi @muchris

Thank you for the code

Yes, it is related to browser caching, shouldn’t cause a redirect issue but I still wonder why the plugin is adding the code if is disabled, could you verify:

– Check on wp-config.php if define(‘wp_cache’, true) still exist, if so, remove it.
– Go to the wp-content folder and verify if the advanced-cache.php file is there, if so, also remove it
– Confirm if the hummingbird folder still exists on the wp-content > plugins folder, in case so, try to remove the folder.

In case the issue persists, I suggest taking those troubleshooting tests: https://www.wpbeginner.com/wp-tutorials/how-to-fix-error-too-many-redirects-issue-in-wordpress/ to find why it is happening.

Let us know the result you got.
Best Regards
Patrick Freitas

Hi @muchris,

That’s odd, since the plugin is deactivated it shouldn’t re-write the .htaccess file with Humminbird rules.

Can you please confirm if you have tried the “Deactivate All WordPress Plugins” step mentioned in the article that we have shared? If yes, can you please also try changing the theme and check if that brings any changes?

The following article can guide you with changing the theme manually using the database: https://www.wpbeginner.com/beginners-guide/how-to-properly-change-a-wordpress-theme/#how-to-change-wordpress-theme-manually

Please let us know the results so that we can further check this for you.

Kind Regards,
Nebu John

Hi @muchris

Thanks for response!

Let me get back to the “.htaccess being rewritten: it’s not “odd” but actually impossible for Hummingbird to write to .htaccess if Hummingbird is not even installed, unless either .htaccess is somehow “restored” automatically from some sort of backup or… if the code was never removed from it.

What I mean is:

1. Hummingbird can write to .htaccess and add such code but
– it cannot do it if it’s not active on site
– if it’s removed it does not leave any script behind that could write it on its own
– and it doesn’t “instruct WordPress” to keep re-adding this code

2. It is unlikely but possible that .htaccess is somehow protected in a way that when you try doing changes it’s being restored; some hosting security feature could possibly behave that way; I wouldn’t expect it but it’s not impossible;

3. It’s quite possible that even if you try to manually remove the code from the .htaccess, these changes are actually simply not saved because .htaccess is protected from writing into it; it would be a file permissions issue and is quite common; depending on a tool used to editing the file – there may be no warning about file not being writable.

Taking that into account, can you make sure that .htaccess is writable at all (so permissions are e.g. like 750 or 660) and then again try editing the file and manually removing those rules? Once you confirm they are fully removed, try setting .htaccess permissions to 444 (so it’s read-only).

Getting back to redirect though: the code that Hummingbird added is solely for setting “expiration headers” – telling browser for how long should it cache given types of files. It doesn’t instruct server or browser to perform any kind of redirect.

Since the code is related to browser cache we could assume that with no site’s assets cached, browser should behave nicely and there should be no redirect, right?

Yet, I’ve visited your /wp-admin page which I have never visited before and I was also stuck in that loop. Furthermore, there’s important information in request headers (you can see it in browser console):

X-Redirect-By: WordPress

This is one of response headers during this redirect loops and it means that redirect was made by… WordPress, not a server or browser.

So the reason is different than code in .htaccess.

I’m not saying that it isn’t related to Hummingbird (though the fact it happens even if Hummingbird is not installed would suggest that it’s not) but it seems to be some sort of conflict or misconfiguration (often it’s some misconfigured security feature).

That being said, I see that the /wp-login.php page is loading just fine and displaying the login form:

– if you try to login there – are you able to login or are you also trapped in that redirect loop?
– what about if you try the same (login via /wp-login.php) in incognito browser window?

Also, since you tried deactivating all plugins:

– are there any files inside “/wp-content/mu-plugins” folder? If yes, what are they?
– have you tried clearing server-side cache – if there is any?
– did the site have, by any chance, domain changed recently or was switched from “http” to “https” or was migrated from one hosting to another?

Kind regards,
Adam