To replicate:

A 5.7 install, on a content type (in this case, a blog post) with no form of access control installed.

Create the blog post. Hit submit. Click the edit tab on the newly created node. Edit the node. Hit submit. Get whitescreen, and eventually the error message that "Firefox has determined that the page is being redirected in a way that will never complete.

Then, on every page load, you see the repeated message in the attached screenshot.


tomaszx’s picture

Priority:Normal» Critical

the same with Drupal 6.3

smk-ka’s picture

Status:Active» Postponed (maintainer needs more info)

Doesn't happen for me on a fresh installation (tested with 6.x-2.0). Either there is another module interfering (a list of enabled modules would help), or your description is not accurate enough to reproduce this issue.

bonobo’s picture

Back when I initially reported the bug, I had it on a completely vanilla install -- core plus checkout, nothing else. I can't speak for the 6.x version, though, as I haven't tested that yet.

tomaszx’s picture


referer_uri(), GET['q'] and clean urls ?

i use clean urls and have problem.

EDIT: i checked witch normal urls and all work ok.... where is problem with clean urls???

smk-ka’s picture

Status:Postponed (maintainer needs more info)» Needs review
new1.08 KB

Could you please try the attached patch and see if it helps (it applies to D5 and D6 versions)?

tomaszx’s picture

Status:Needs review» Postponed (maintainer needs more info)

Yeah,... cool, work but i have still this:

"This document is locked for editing by Tomek since sob., 12/07/2008 - 00:33.
Click here to check back in now."

on non clean urls this not hapen when i click elsewhere :)

thx. for fast reply.

good module :)

tomaszx’s picture

Status:Postponed (maintainer needs more info)» Reviewed & tested by the community

hm, too fast i reply ...

i found:

node/211/edit = ~tomasz/ni/content/burnproof-i-overburn

maybe pathauto?

smk-ka’s picture

Can you tell me a little bit more about the path on the right side: which elements of the path are belonging to the path alias? I can imagine "content/burnproof-i-overburn" would be the alias, but where is "~tomasz/ni" coming from?

tomaszx’s picture

Status:Reviewed & tested by the community» Postponed (maintainer needs more info)

i test on localhost with rewite base. never mind, problem is one:

clean urls. when i turn off are work ok.
your solution with :

if ($_GET['q'] == $referer) {

this is not enough :(
i search in code and when i found some idea then tell you ... thanks for help and reply.

smk-ka’s picture

Status:Postponed (maintainer needs more info)» Needs review
new1.48 KB

I think I've got it fixed. Could you please test again, Tomasz?

tomaszx’s picture

Status:Needs review» Reviewed & tested by the community


Yeah! Now this work like on non clean urls - just good. Thanks for your work. Good job.
I think that you can apply this patch to module and release.

Once thanks.

smk-ka’s picture

Status:Reviewed & tested by the community» Fixed

Thanks for testing, Tomasz.

Committed to D5 and D6 branches.

Frank Steiner’s picture

Version:5.x-2.x-dev» 6.x-2.2
Status:Fixed» Active


it still happens when using prefixes for languages. E.g., when I edit a language neutral page in my default language, the path is sth. like "node/138". When I switch to english (with the page still the same, because it is language neutral), the path is "en/node/138". When I edit the node and click save, I run into the endless redirection loop again because

current path: node/138/edit
referer: en/node/138/edit

Maybe we can ignore everything before "node/"? Please see also, maybe both bugs can be hit with changing one regexp?
Frank Steiner’s picture

Status:Active» Needs review
new1.2 KB

The problem is that $_GET['q'] gets the language prefix removed in language_initialize which is called for every page, but referer still contains it, so your patch doesn't work when using language prefixes.

The patch cleans $referer from a language prefix if it exists. Note: the patch doesn't fix Additional patch there.

sebos69’s picture

I can confirm having the same issue, and that the patch in comment #14 fixes the problem. Thanks!

Frank Steiner’s picture

If someone who tested it would set the status to "Patch reviewed and tested" it might help making smk-ka consider it :-)

sebos69’s picture

If someone who tested it would set the status to "Patch reviewed and tested" it might help making smk-ka consider it :-)

I could do that, but my knowledge of php resumes to:

patch  -i ../checkout_clean_referer_from_lang.patch

so, the testing is OK from my side, but reviewing should be done by someone would actually understands php :)

Frank Steiner’s picture

I see ;-)

Mike Sances’s picture

Having same issue when: Editing the page, then clicking "Preview", then clicking "Submit."

Have tested by disabling checkout module, and this removes the error.

Mike Sances’s picture

Tried the patch from #14, this didn't fix the issue.

nik78’s picture

Strange... but good for me, using 6.x-2.2 with patch from #14 works for me on my devel and production site (without the patch i had the redirect problem because of language prefix).
My php knowledge is sorryly very low so i better don't change the status of this bug.

mbria’s picture

Version:6.x-2.2» 6.x-2.x-dev

Same issue with lang prefixes in url and last dev release.

Frank Steiner’s picture

The dev version doesn't contain the patch, could you test it?

I've no idea why smk-ka doesn't take a look at the patch :-(

sun’s picture

Status:Needs review» Needs work

@@ -197,6 +197,19 @@
     $referer = drupal_get_normal_path($referer);
+      $referer = preg_replace("?^". $language->prefix ."/?",'',$referer);

We want to munge $referer before invoking drupal_get_normal_path().

+  // $_GET['q'] doesn't have a language prefix, referer_uri does (if defined).
+  // Remove it from $referer to enable comparison with $_GET['q'].

Please append () when referring to function names in comments. Also, we can shorten this to Strip potentially contained language prefix from referer_uri(). or similar.

+    // Check language_negotiation mode because prefix can be defined without
+    // using it in URLs, and someone could define a fixed path starting
+    // with the same string as a language prefix.

Can we shorten this comment and make it up to the point? Something like Language path prefix can be configured independently from language negotiation mode, and we must not remove false-positives. or similar.

+    switch ($mode) {

Wrong indentation here.

+      $referer = preg_replace("?^". $language->prefix ."/?",'',$referer);

If you use ? as delimiter, you need to preg_quote() $referer accordingly. Please use @ or similar instead. In any case, preg_quote($referer, '@') is required. Please also fix the spacing (after commas) in this line.
simonmd’s picture


smk-ka’s picture

Not tested yet, but the proposed solution might not work in case a language has been switched while being on a locked node, since only the current language is considered. My guess is that we need to match all available languages instead to be on the safe side.

smk-ka’s picture

Status:Needs work» Needs review
new2.47 KB

Now, I am everything else than sure about this new patch, which incorporates almost a 1:1 copy of language_initialize(). However, I think we need to be able to determine the correct language of the referring URL, because otherwise drupal_get_normal_path() won't be able to resolve the internal path, and that would be bad. It would be extremely helpful if somebody with a real-world multilanguage setup could test this patch and report back. Of special interest here, as written in my last comment, is switching the language while on a node edit page, which should still leave the node locked (ie. display no messages).

Sebastian’s picture


Leeteq’s picture


Frank Steiner’s picture

I can confirm it works for me, but I've only two languages and the default one is without a prefix, so I don't hit your improvement.

But at least it fixes the original bug for a two-language site, so it's better than nothing :-)

Kpolymorphic’s picture

new4.82 KB

This is against the 6.x version.

I pursued a little bit different take on the problem; since, even with the latest patch, I had issues with other kinds of prefixes:
- moved the check in code to hook_nodeapi() ($op == 'prepare')
- the non-persistent lock seemed a poster-child for sessions, so, I used sessions to eliminate all of the regexing on paths
- it then made sense to make clearing of non-persistent locks a cleanup task, so I killed the hook_init() in favor of hook_exit()

The problem with this patch is the loss of locking on revisions. No idea if this is an acceptable loss; but, I thought I would provide the patch anyways.

cels’s picture


John Morahan’s picture

new2.96 KB

While this removes the need to parse out the correct path from the referrer (which is a good thing IMO), it also removes the ability to lock multiple nodes at the same time, in multiple tabs for example.

Here's a related approach that stores the mapping from the current full URL to path in the session, and looks up that table to find the referer path. If the language switches, or for any other reason the path aliases change, it shouldn't matter because the previous path is already stored.

This patch was developed for Capgemini by IO1

kmonty’s picture