Page being redirected in a way that will never complete

the same with Drupal 6.3

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.

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.

maybe:

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???

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

Attachment	Size
checkout.module.patch	1.08 KB

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 :)

hm, too fast i reply ...

i found:

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

maybe pathauto?

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?

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) {
return;
}

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

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

Attachment	Size
checkout.module.patch	1.48 KB

Hi,

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.

Thanks for testing, Tomasz.

Committed to D5 and D6 branches.

Hi,

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

Maybe we can ignore everything before "node/"? Please see also http://drupal.org/node/285702, maybe both bugs can be hit with changing one regexp?

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 http://drupal.org/node/285702. Additional patch there.

Attachment	Size
checkout_clean_referer_from_lang.patch	1.2 KB

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

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

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 :)

I see ;-)

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

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

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

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.

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

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 :-(

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

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.

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.

Wrong indentation here.

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.

Suscribing

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.

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).

Attachment	Size
245685-checkout-language.patch	2.47 KB

Subscribing

Subscribing.

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 :-)

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.

Attachment	Size
alt-checkout.module.patch	4.82 KB

Subscribing