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.

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

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?

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.

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.

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

@@ -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) {
+    case LANGUAGE_NEGOTIATION_PATH_DEFAULT:
+    case LANGUAGE_NEGOTIATION_PATH:

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.

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

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.

Subscribing

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

Subscribe