Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
When pathauto, globalredirect and path_redirect enabled together, there are conditions under which an infinite redirection loop occurs.
I will provide more details on the problem if needed. for now i am just attaching the patch which should be commited :)
Comment | File | Size | Author |
---|---|---|---|
#18 | path_redirect_n281521_v5.x-1.x-dev.patch | 1.04 KB | DamienMcKenna |
#8 | path_redirect_infinite_loop_fix_drupal6.patch | 7 KB | alexandermeindl |
path_redirect_infinite_loop_fix.patch | 1.9 KB | litwol |
Comments
Comment #1
eaton CreditAttribution: eaton commentedWent through the fix with litwol and think this is probably the safest way to solve it, with the fewest ripple effects.
Comment #2
gregglesI believe those conditions were found and squished (both in Pathauto and in path redirect).
See #218277: prevent endless forwarding when the redirect points to a node that represents itself for the fix to path_redirect.
This issue is newer than 218277, but since you're not using cvs I can't tell which exact revision this is against. Can you clarify what the steps are to cause this and whether or not they are still present?
Comment #3
litwol CreditAttribution: litwol commentedYes the problem still exist. the following is code in path_redirect that prevents infinite redirects on itself.
is causing an infinite loop; redirect cancelled.', array('%redirect' => $r->redirect)), WATCHDOG_WARNING, l(t('edit'), 'admin/build/path-redirect/edit/'. $r->rid));
}
however bear in mind that when global redirect module comes into play things change. the infinite loop happens one step after the path_redirect have issued it's redirect.
here's the cycle:
1) user comes to /old-url-alias
2) path_redirect bounces him off to the node/### of the old alias
3) user arrives at node/###, global redirect looks up if node/### maps to an alias, if so it redirects the user to /new-url-alis
4) user arrives at /new-url-alias. path_redirect checks if /new-url-alias exists in path_redirect.path and if so bounces it off to node/### which is step (2) above. hence the cycle continues for ever.
the key condition that triggers this is having path_redirect.path equal to url_alias.dst which doesnt make sense (the old alias is equal to the new one ?)
my patch prevents such records from being written.
Comment #4
gregglesWhat are the steps in node creation/editing that lead to the cycle you identified?
Comment #5
litwol CreditAttribution: litwol commentedjust a typical edit/save, we haven't done anything special that may have triggered this. just a normal edit/save.
Comment #6
gregglesPersonally I wouldn't commit something without a set of steps to repeat but this isn't my queue so I'll set the status back.
Comment #7
Todd Nienkerk CreditAttribution: Todd Nienkerk commentedI've had this happen to me, too, using Global Redirect and Pathauto 2.3 with the update action set to "Create a new alias. Redirect from old alias." Editing and re-saving the node appears to add the same path to the alias *and* redirect tables, creating an infinite loop.
Comment #8
alexandermeindl CreditAttribution: alexandermeindl commentedHi,
I converted the patch to Drupal6 (latest path_redirect dev version)
Comment #9
chowzer CreditAttribution: chowzer commentedHow do I apply or use this patch on my site that is currently experiencing this Redirect Loop problem? I am a non-programmer user of Drupal.
I am using Drupal 6.6 and am tearing my hair out because of this issue. I have disabled all contributed modules and still the problem persists.
I do not have the globalredirect module on my site at all, while pathauto is disabled.
Comment #10
Todd Nienkerk CreditAttribution: Todd Nienkerk commented@chowzer: Here's a how-to on Drupal.org: Applying patches. If command-line stuff makes you go cross-eyed, try these:
Comment #11
Todd Nienkerk CreditAttribution: Todd Nienkerk commentedJust curious: What's the status of these patches? Have they been included in any official releases or dev versions?
Comment #12
Dave ReidI've just been added as a co-maintainer and I'm starting to evaluate and test all the backlogged patches in the queue. I'm also working on a test suite for the path_redirect module so that all these bugs don't pop up again. BTW, I have fixed all the coder warnings that were in patch #8 on 6.x-1.x.
Comment #13
Todd Nienkerk CreditAttribution: Todd Nienkerk commentedDave Reid: Excellent news! If you need anybody to help you test, let me know. And if you're working within a particular testing suite, will you consider making an install profile to speed up the testing process?
Comment #14
DamienMcKennadavereid: Awesome. Would you like some help testing/verifying this patch in D5 so that it can be added to the next release? We're having tons of watchdog messages about this issue.
Comment #15
Dave Reid1. Can I have some users please confirm that this bug is still affecting the latest 5.x-1.x?
2. If it still is, could someone please clean up the patch in #8 to follow core coding standards?
Comment #16
Dave ReidComment #17
Dave ReidIn addition, this check needs to be done in path_redirect_edit_validate() instead of path_redirect_save() so that an error message can be displayed to the user if they hit this condition. If I'm a user and don't realize I'm creating an infinite loop condition, the redirect I create is simply going to disappear even though a "Redirect has been saved" message is shown. Also, the path_redirect_cron() run should probably just be an update function as well instead of cron.
Comment #18
DamienMcKennaAn updated patch for v5.x-1.x-dev, please test.
Comment #19
DamienMcKennaComment #20
natrio CreditAttribution: natrio commentedsubscribing
Comment #21
silentflight CreditAttribution: silentflight commentedPatch not working for me - have looked at everything and do not seem to be able to get this to work - as soon as I activate Global redirects, it kills everything except the front page.
Could someone possibly assist me sorting this out as it is crucial to a site that is currently running.
Drupal 5.16 running all the latest versions of pathauto, globalredirect and path_redirect.
Comment #22
AppleBag CreditAttribution: AppleBag commentedOne of my users changed their name in their profile today and now it's still showing the user's old path to their profile when hovering the cursor over their name/link, rather than the new url to their profile. When someone clicks their name (which is supposed to take them to their profile) it says Page Not Found, and in the watchdog it says this:
Redirect to user/20 is causing an infinite loop; redirect cancelled.
So for example:
User's Name is Bob, profile url is http://mysite.com/users/bob
User changes their own name to John, url *should* automatically change to http://mysite.com/users/john, but is staying at http://mysite.com/users/bob, and clicking it results in that error.
Any ideas anyone?
Comment #23
Lars Vandergraaf CreditAttribution: Lars Vandergraaf commentedComment #24
Lars Vandergraaf CreditAttribution: Lars Vandergraaf commentedOk I had no luck applying this patch. Many confusing comments on drupal about applying patches. Perhaps each developer likes doing their own thing. This what I did to use this patch.
a) I tried putting this patch in the ../sites/default/modules folder I went to terminal and cd'd to the directory holding the patch and ran the following command: patch -p0 < path-redirect_infinite_loop_fix_drupal6_0.patch
failed with hunk errors
b) started over with a clean slate and I put the patch in ../sites/default/modules/path_redirect and I cd'd to that directory and ran the following command: patch -p0 < path-redirect_infinite_loop_fix_drupal6_0.patch
failed with hunk errors
c)I tried this as well after deleting the path_redirect folder and copying my backup version. I put the patch in this new refreshed copy of path_redirect and ran
$ patch < path_redirect_infinite_loop_fix_drupal6_0.patch
patching file path_redirect.admin.inc
Hunk #1 succeeded at 128 with fuzz 1 (offset 126 lines).
Hunk #2 FAILED at 248.
1 out of 2 hunks FAILED -- saving rejects to file path_redirect.admin.inc.rej
patching file path_redirect.install
Hunk #1 FAILED at 2.
Hunk #2 FAILED at 101.
2 out of 2 hunks FAILED -- saving rejects to file path_redirect.install.rej
patching file path_redirect.module
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 19.
Hunk #3 FAILED at 65.
Hunk #4 FAILED at 111.
Hunk #5 FAILED at 121.
Hunk #6 FAILED at 217.
6 out of 6 hunks FAILED -- saving rejects to file path_redirect.module.rej
I am not a developer. It would be great if each patch came with instructions on how to apply since I think directory location has something to do with success.
Comment #25
TommyK CreditAttribution: TommyK commentedThe path being added to both the alias and redirect tables is still occurring with 6.x-1.0-beta6, but I tried out the current dev (2010-Mar-18) and I don't have the problem. All without applying any patches.
Comment #26
OldAccount CreditAttribution: OldAccount commentedThe patch wouldn't install for me either but switching to 6.x-1.x-dev seems to have fixed the issue for me, thanks TommyK!
Comment #27
OldAccount CreditAttribution: OldAccount commentedI spoke too soon, the problem is still happening. I have to go into URL redirects (admin/build/path-redirect/list) and delete existing entries before I make any changes.
Comment #28
dbutcher2010 CreditAttribution: dbutcher2010 commentedI am not a Drupal expert, so please educate me if I am seeing normal behavior. I just migrated a site from a staging server to a production server. It's Drupal 6.17, Path Redirect 6.x-1.0-beta6 (no Pathauto).
Unfortunately, the original authors used full URLs in the URL path settings field when they created pages. After migration, the URL path settings were edited to remove the staging server name. As far as I can tell (and reproduce) every time the server name was edited out the the page saved, a redirect was created, AND the corresponding URL alias was updated. Looking at the Path Redirect module code, it seems a redirect is created any time the URL path on a node is updated, including an update/deletion of the server name.
In our case, if the the redirect creation could be controlled by a checkbox we would have been able to leave it unchecked.
Am I missing a configuration that would have given us control over the redirect creation? As it is now, every page we updated is giving an infinite loop redirect warning. We have lots of "real" redirects so we have a mix of "auto" and "real" redirects now. Is that the expected outcome after making the URL naming mistake we made and fixing it? Thanks for tips, explanations, comments.
Comment #30
narcissus921 CreditAttribution: narcissus921 commentedSubscribing, currently having infinite redirection loops periodically.
Using:
Path redirect 6.x-1.0-beta6
Pathauto 6.x-1.4
Global Redirect 6.x-1.2
Comment #31
Anonymous (not verified) CreditAttribution: Anonymous commentedSubscribing - any progress with this? Using 6.x-1.0-rc2 and I'm still getting these errors (also using pathauto and global redirect).
Comment #32
splash112 CreditAttribution: splash112 commentedHad some problems with language neutral nodes that were causing a redirect loop with Language Path Checking and Domain Name Only. Solved it by adding a check before the redirect.
Comment #33
antoineplasait CreditAttribution: antoineplasait as a volunteer commentedCould be nice to give some details.
I have the same issue. Everything is working properly (redirection...) except that I just created a new content type within neutral language. And I can't access those nodes because they are in a redirection loop.
It goes to mydomain.fr to mydomain.com over and over.
Thanks.