WordPress 1.2.1 Redirection Limit For this URL

What happens if you go into the database itself, create a user and password, and then try to log in with that user/pass combo?
BTW, the password will have to be hashed of course… ??

Same result with a manually created login. Same error.

I experienced this error on a plugin I was developing. My fix revolved around realising that I had a header() function with an improper value, which FireFox wasn’t able to sensibly resolve.
I can’t comment any more specifically than that on your situation (mainly because I’m not experiencing the behaviour you’re describing on my installation), as I guess it could be any of a number of things, but if you’re comfortable looking at the code yourself, a starting place might be any header() calls being made in the login pages that might be being passed an invalid URI.
Much warmth,
planetthoughtful

Anyone have a specific fix for this issue? It seems like its pretty common:
https://www.google.com/search?q=wordpress+redirection+limit

I don’t have a fix, but it has to be some sort of browser issue maybe. I often get this error using MT, when I’ve received an email notifying me of a comment, then click the email link to go approve the comment in the MT interface.
So it may not be just WordPress causing the problem.

I should have made this more clear but it is not a browser issue. I’ve tried this on every major browser on every major platform. (windows, OSX, Linux).

I don’t think it’s so much a browser issue, as I suspect (note the emphasis) that it’s a PHP / your host issue.
Specifically, I can’t help feeling it might have something to do with the way the browsers are being asked to behave in response to a header redirect and mod_rewrite / .htaccess rules etc. Somewhere in there it seems that a loop is being created that expires the browsers’ ability to sensibly redirect the page, and it lets you know that.
This would also explain why it’s happening on some installations and not others. After all, if you remove the browser as the culprit (as asv seems to have done) and you remove the installation of the package as the culprit (as is implied by the fact that only some are being affected by this, while many aren’t) then all you are left with is something different about the affected users’ hosts or some edit they’ve made (ie plugin / hack and so on) to their own installation.
I guess all we can do is ask those affected to be as descriptive of their host environments and any changes they’ve made and wait for a sensible pattern to emerge.
Much warmth,
planetthoughtful

planetthoughtful,
Thanks for very helpful repspones! I was starting to suspect the apache2 configuration as well. I have a few gentoo servers so I’m going to try installing wordpress on another machine to see if I get the same errors. I have also posted my apache conf here:
https://alexvalentine.org/asv/
Maybe someone will see something out of the ordinary.

Hi asv,
You’re more than welcome — I just wish I could give you a straightforward solution.
I’d love to hear the results your server experimentation delivers — I’m sure we could go a long way towards minimising a segment of WP users’ frustrations if we could solve this issue.
Looking forward to hearing how you get on with this!
Much warmth,
planetthoughtful

I noticed this after an update, too.
For me the problem was resolved after deleting all cookies from my site in Firefox.
I did not logout from the old version of WordPress. Maybe the cookies do not match anymore after an Update?
Maybe you have accessed your site with every browser you tried before? And every browser you tried has “old” cookies from your site?

So what I ended up doing was not using the gentoo ebuild and using the tradional install method. So I’m guessing its a bug in the ebuild and not in wordpress or the ebuild is using an old tarball.

AAH! This is my problem exactly. And I too have Gentoo Linux. I’ve tried both 1.2.1 from portage and I dumped it for the 2004-11-02 nightly build and I have the same trouble with either. But from looking at the Apache logs, it is definitely caught in a loop of some kind. Perhaps someone more familiar with WP will recognize the problem:
192.168.0.4 - - [05/Nov/2004:19:47:50 -0600] "GET /wordpress/wp-admin/ HTTP/1.1" 302 - "https://192.168.0.4/wordpress/wp-login.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041029 Powerslug/1.0RC1 (All your Firefox/1.0RC1 are belong to Firesomething)"
192.168.0.4 - - [05/Nov/2004:19:47:50 -0600] "GET /wordpress/wp-login.php?redirect_to=%2Fwordpress%2Fwp-admin%2F HTTP/1.1" 302 - "https://192.168.0.4/wordpress/wp-login.php" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041029 Powerslug/1.0RC1 (All your Firefox/1.0RC1 are belong to Firesomething)"

After erasing everything and starting over multiple times, I have found a workaround that lets me install – and login!
I first installed 1.2.1, ran /wp-admin/install.php and when I tried to login, get the Redirection limit exceeded error.
Then I deleted the cookies and closed the browser window.
Then I removed the 1.2.1 files and replaced them with the 2004-11-02 nightly build.
Then I ran /wp-admin/upgrade.php and logged in successfully.
Aside from having to run a nightly build, everything seems to be fine. New version looks good, too!

Just had the exact same problem with an upgrade, viewing it in Firefox … clearing out cookies solved it …

Well I’m not downgrading now. The nightlies are working well…