Hello there,

I just upgraded from Drupal 5.x to 6.8, and in the process I also upgraded to the 6.x-1.0 version of Global Redirect. It caused every page except for the front page to be completely inaccessible (Redirect Loops). I couldn't even turn GR off. I finally had to delete it manually via FTP. I uploaded the 6.x-1.x-dev version, and that appears to have fixed the problem.

Just wanted to share my experience in the hopes it might be helpful.

Cheers.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

avolve’s picture

i just noted this with MAMP - i had to delete the module to access the modules pages (i did not try any other pages). Was not upgrading this module, just installing it. Got a message in FF about the loop...

WildBill’s picture

Forgive me - what does MAMP stand for?

nicholasThompson’s picture

Just as LAMP is "Linux, Apache, MySQL, PHP", MAMP is the same for Mac OS X (Mac, Apache, MySQL, PHP).

nicholasThompson’s picture

Status: Active » Fixed

As 6.x-1.x-dev fixed the issue and that is going to become 1.1 as soon as this issue queue is sorted, I'm marking this as fixed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

okokokok’s picture

Status: Closed (fixed) » Active

I'm running the latest version of Global Redirect on Drupal 6.10 on a multi-site install. On some sites Global Redirect is giving me the redirect loops, but not on other sites.

The redirect loops occur almost everywhere in the site, apart from the main page. This is probably the reason that Global Redirect doesn't show up in update.php either. Could this be part of the problem?

xaviercas’s picture

Drupal 6.10
MySQL database 5.0.51a
PHP 5.2.6
Web server Zeus/4.3
Global Redirect 6.x-1.2
Path enabled
Pathauto installed not enabled

Hi,

I am also getting redirect loops. All running ok now that GR has been disabled, after having not been able to access the site . Now, when I try to enable the module, it causes the same problem, not even going through the 'save configuration' process. Thanks.

okokokok’s picture

It could be related to the web server. I am running nginx. Is anyone running Apache encountering this issue?

Clemens’s picture

Version: 6.x-1.0 » 6.x-1.2

Confirming the Redirect Loop issue in Drupal 6.12 with Global Redirect 6.x-1.2 and Pathauto 6.x-2.x-dev on Apache.

Turn Global Redirect OFF and all is OK again.

Edit: added reference to Apache.

WildBill’s picture

I'm using Global Redirect 6.x-1.x-dev with Pathauto enabled, and I'm not having the Redirect Loop issues. However, I don't believe my Pathauto and Drupal core are up-to-date right now (my site is in development).

That said, the dev version appears to have fixed this problem.... so are we planning to roll this fix into the official release?

xaviercas’s picture

Drupal 6.12
MySQL database 5.0.51a
PHP 5.2.6
Web server Zeus/4.3
Global Redirect 6.x-1.x-dev

I have installed GR 6.x-1.x-dev and had the same problem as before: redirect loop. Deleted the module via ftp as I could not access the site.

hongbo’s picture

I notice one case it will loop:

A url rewrite is added in .htaccess to add a slash at end of the language prefix, such as to change http://domain.com/en to http://domain.com/en/

Because globalredirect will remove the end slash after language prefix regardless if the 'deslash' option is on of off.

I have made a patch to preven globalredirect from removing the end slash after language prefix.

http://drupal.org/node/481690

smk-ka’s picture

Title: Redirect Loop in 6.x_1.0 » Redirect Loop and custom_url_rewrite ignored
Assigned: Unassigned » smk-ka
Priority: Normal » Critical
Status: Active » Needs review
FileSize
1.54 KB

This module is missing critical updates that happened between Drupal 5 and 6:

1. It completely ignores language in calls to drupal_get_path_alias() and the $alias_sensitive query
2. custom_url_rewrite() was formerly triggered by drupal_get_path_alias(), since D6 you have to do it manually (see url() function as reference).

By not correctly re-assembling the URL to compare to, this module breaks other modules like Sub-path URL aliasing (issue).

PlayfulWolf’s picture

seems that this patch still haven't made to dev version :(

mrfelton’s picture

Patch fixes the issue for me (using Sub-path URL), thanks.

phdhiren’s picture

Status: Needs review » Reviewed & tested by the community

thanks smk-ka

I was having problem when Global Redirect and Subdomain modules are together.

Patch in #13 works for me too.

jcmarco’s picture

Tested and working fine.
I had problems with subpath_alias module and now it works fine.

nicholasThompson’s picture

I'll try to commit this patch to 6.x-dev this weekend.

Cheers for all the reviews guys!

Nick

mczenko’s picture

Works great ! Thanks !

Steven Jones’s picture

This patch doesn't fix the problem when used with PURL, as in #527490: PURL + Path Aliases = Redirect loop, in fact it makes it a little worse.

a.a.egoroff’s picture

Tested on D6.13 with:
path.module
subpath_alias.module
url_alter.module

Also tested with hardcore aliases:) admin/* -> panel/*, node/* -> contents/*… altered subpaths:
/panel/build/menu (/admin/build/menu)
/panel/build/block (/admin/build/block)

all many others work fine!
Thanks a lot!!!

jcruz’s picture

Patch #13 works for me.

Tested with:
Drupal 6.13
pathauto 6.x-1.1
globalredirect 6.x-1.2
subpath_alias 6.x-1.0

klonos’s picture

Hey people, I am having issues too with:

Drupal 6.13
pathauto 6.x-1.1
globalredirect 6.x-1.x-dev or 6.x-1.2
subpath_alias 6.x-1.0

Is this patch included in latest dev build (6.x-1.x-dev, 2009-Jun-12)?

If not, how do I apply it?

Can it only be applied on 6.x-1.2 or does it also work on 6.x-1.x-dev?

Can anyone provide an already patched version of either the dev build or the 6.x-1.2 pretty please?

mdih’s picture

Patch #13 works for me.

Tested with:
Drupal 6.13
pathauto 6.x-1.1
globalredirect 6.x-1.2
subpath_alias 6.x-1.0
url alter 6.x-1.0
Path redirect 6.x-1.0-beta4

To apply patch manually: http://drupal.org/node/534548

dinwath’s picture

Patch #13 works for me.

Tested with:
Drupal 6.12
pathauto 6.x-1.1
globalredirect 6.x-1.2
subpath_alias 6.x-1.0
url alter 6.x-1.0

Thanks a lot!!!

tim.plunkett’s picture

#13 works!
Drupal 6.13
globalredirect 6.x-1.x-dev
pathauto 6.x-1.x-dev
subpath_alias 6.x-1.0
url_alter 6.x-1.1

Thanks!

xjm’s picture

Applying the patch in #13 resolved the issue for me as well. I guess we're listing our module versions here so:

Drupal 6.14
Global Redirect 6.x-1.2
Path Redirect 6.x-1.0-beta4
Pathauto 6.x-1.1
URL alter 6.x-1.1
Sub-path URL Aliases 6.x-1.0

lort’s picture

patch attached to #13 works for me too.

Drupal 6.14
Global Redirect 6.x-1.2
Path Redirect 6.x-1.0-beta4
Pathauto 6.x-1.1
URL alter 6.x-1.1
Sub-path URL Aliases 6.x-1.0

BenK’s picture

Subscribing....

crea’s picture

subs

Dave Reid’s picture

Status: Reviewed & tested by the community » Needs review

Can someone try with some revised logic that matches how the url rewriting works in D7?

    $original_request = $request;
    if (function_exists('custom_url_rewrite_outbound')) {
      // Modules may alter outbound links by reference.
      custom_url_rewrite_outbound($request, $options, $original_request);
    }

    // Aliases should always take precendence over any altered URLs.
    $alias = drupal_get_path_alias($original_request, $options['language']->language);
    if ($alias != $original_request) {
      $request = $alias;
    }
tim.plunkett’s picture

Assigned: smk-ka » Unassigned

Patch? I'm not exactly sure if should modify or replace the patch provided, so I'm hesitant to vouch for it, but it makes sense.

dyke it’s picture

i was having a related problem (described here: http://drupal.org/node/632176) and the patch at #13 fixed the problem.

Drupal 6.14
Global Redirect 6.x-1.2
Pathauto 6.x-1.2
URL alter 6.x-1.2
Sub-path URL Aliases 6.x-1.1

doq’s picture

FileSize
1.6 KB

Code clean-up.

FiNeX’s picture

Subdomain has been patched, does this fix solve the problem reported here?
http://drupal.org/cvs?commit=305572

Dave Reid’s picture

No, we still need this committed to Global redirect.

Dave Reid’s picture

Status: Needs review » Reviewed & tested by the community

Latest patch looks good to me.

servantleader’s picture

+1

JimmyAx’s picture

Patch at #13 worked great for me.

dashton’s picture

I had a similar problem with GR when I setup a custom_url_rewrite to change /admin to /config because of a server conflict. I got an error that too many redirects were being executed.

I had to go into the database and turn off GR to get the site working again. Does this patch address that issue? I'm using the latest GR for D6, downloaded it today.

popetardo’s picture

patch #13 works fine for me too.
drupal 6-15.

nicholasThompson’s picture

Exellent! Thanks guys - I'll get #13 committed asap! :)

TripleEmcoder’s picture

So when will this be available in dev or a release?

venusrising’s picture

When will this be ready for release. Thanks so much

arski’s picture

works like a charm! can't wait to see it in -dev or, even better, in a release :)

Thanks

AdrianB’s picture

Subscribing

Deg’s picture

Subscribing

ralizav’s picture

Thanks!
#13 patch work fine

Drupal 6.15
Global Redirect 6.x-1.2
Pathauto 6.x-1.2
Sub-path URL Aliasing 6.x-1.1
Url alter 6.x-1.2

vzsze’s picture

#13 patch fixes the probleme here. Thank you.

iva2k’s picture

subscribe

j0nathan’s picture

subscribing

Dave Reid’s picture

@nicholasThompson/maintainers: We're starting to get more than a few issues backed up and its been over a year since the last stable release. I've filed a request to help co-maintain if you need someone with a little time and love to help keep the module updated: #731396: Application for Dave Reid to join as co-maintainer (is Global Redirect maintained?).

xjm’s picture

Thank you, Dave!

Dave Reid’s picture

Status: Reviewed & tested by the community » Fixed

Committed this to 7.x-1.x and 6.x-1.x. Thanks everyone!
http://drupal.org/cvs?commit=336578
http://drupal.org/cvs?commit=336580

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

arski’s picture

Hey, this is closed already! Any chance of seeing it in a release?

Thanks!

jrearick’s picture

Kind of bad this patch has been available sine July '09 and the recommended release hasn't been updated. Setting up a brand new installation I ran into this issue, the patch seems to work fine for me. Should I be using the development release?

charlesjc’s picture

I too would like to see this rolled up into a release soon.

Please...

tomsm’s picture

Me too...

nickl’s picture

Version: 6.x-1.2 » 6.x-1.x-dev
Assigned: Unassigned » nickl
Status: Closed (fixed) » Needs review
FileSize
3.93 KB

Not sure if this was actually working but it certainly didn't work for me with Persistent URL (PURL) releases 6.x-1.0-beta10 - 12 using path processor.
Global Redirect (GR), 6.x.1.12 but patch rolled against 6.x-1.x-dev, still ignored custom_url_rewrite_outbound when redirecting via drupal_goto('' with blank path, which removes the path completely. If you try to maintain a default path via a custom module's hook_init and the purl_goto method, this custom module will attempt to reassign the path, since GR removed it which in turn promptly removes it again. The two modules will keep playing tit for tat until the browser gives up and aborts.

I opted to use the $prefix variable, since it makes practical sense as well as it's name entails, to collect any possible prefixes by chasing it through custom_url_rewrite_outbound as well and then passing it to the drupal_goto redirect when the $_REQUEST still mismatches.

There was also something funky going on with the $alias $redirect_slash interrogation routine where $prefix is prepended when comparing to $_REQUEST['q'] for the presence of a trailing / to remove. But then $prefix omitted ad $alias alone goes for the drupal_goto redirect causing undesirable outcomes resulting in page not found. Since $alias has already been treated by visits to custom_url_rewrite_outbound and drupal_get_path_alias with $langcode, all $prefixes should technically be applied already. Unless I'm missing something obscurely unobvious.

Removed the $prefix from $alias comparisons and restructured the process of events a tad as they naturally occur one after each other. This patch was only tested with pathauto, PURL, path_redirect and a whole magnitude of other less pertinent modules so more testing will be required.

Looking forward to seeing something bright and exceptional coming from you, who's going to take this delicious bait?

Please review and respond with your findings.

aufumy’s picture

Status: Needs review » Reviewed & tested by the community

global redirect version DRUPAL-6--1-2 and also dev version checked out Jun 1st, did not work with purl DRUPAL-6--1-0-BETA12, ran into redirect loop issue.

After applying patch in #60, the site seems to work for me.

nickl’s picture

Thank you aufumy for reviewing and testing this patch, glad it was to your satisfaction.

Can we please have users without purl apply and test this patch to confirm everything remains in the same working order as expected.

Especially on test installations with the latest versions of the following modules installed and configured to work in conjunction with globalredirect.
pathauto
subpath_alias
url alter
Path redirect

Patch still applies to new dev build May 29, 2010 - 00:07

euchrid9’s picture

I had the same problem on Drupal 6.17, using Global Redirect 6.x-1.2, getting the error message "Firefox has detected that the server is redirecting the request for this address in a way that will never complete." Due to time constraints, rather than test a patch, I had to disable the Global Redirect module by completely removing it; just disabling it on the modules admin page did not work, as it enabled itself without me actioning it - as with the original poster. Not being able to turn the module off seems as big a problem as the redirects - at least until the behaviour is noticed.

awolfey’s picture

I applied the patch in #60 (by hand) using the dev from June 17th, using all the modules listed in #62.

The loop problem is solved.

Block visibility path settings are not aware of the rewritten sub-paths.

I will report back if I notice anything else

kekkis’s picture

Subscribe

vadym.kononenko’s picture

I've recreate #60 to the latest DEV.
The loop problem is solved.

TheDoctor’s picture

Subscribed.

TheDoctor’s picture

Same issue as reported by #63, on D6.19. Specifically, same message appeared when attempting to edit any stories or pages. Swapping in GR 6.x-1.x-dev resolved it. Thanks #66.

  • Global Redirect 6.x-1.x-dev
  • Pathauto 6.x-1.4
  • Path redirect 6.x-1.0-beta7
  • Sub-path URL Aliasing 6.x-1.1
  • Token 6.x-1.14
  • Url alter 6.x-1.2
charlesjc’s picture

Hi,

I have tested Global Redirect 6.x-1.3-alpha1 with:

  • Drupal core 6.19
  • Path redirect 6.x-1.0-beta7
  • Pathauto 6.x-1.4
  • Sub-path URL Aliases 6.x-1.1
  • Token 6.x-1.14
  • URL alter 6.x-1.2

All seems OK.

regards,
Charles

Guo’s picture

Subscribing....

#13 patch doesn't work for me

Drupal 6.19
Global Redirect 6.x-1.2
custom_url_rewrite outbound and inbound
FF3.6.8 was redirect loop...

quicksketch’s picture

Just another +1 here. Global Redirect clearly isn't compatible with custom_url_rewrite_inbound().

For testing, just use these two simple rules in your settings.php and see if Global Redirect will work when visiting a node page:

/**
 * Rewrite paths before outputting.
 */
function custom_url_rewrite_outbound(&$path, &$options, $original_path) {
  // Change all "node" to "content".
  if (preg_match('/^node(\/.*)/', $path, $matches)) {
    $path = 'content'. $matches[1];
  }
}

/**
 * Rewrite incoming paths to the true Drupal paths.
 */
function custom_url_rewrite_inbound(&$result, $path, $path_language) {
  // Change all content/x requests to node/x
  if (preg_match('/^content(\/.*)/', $path, $matches)) {
    $result = 'node'. $matches[1];
  }
}
roderik’s picture

Status: Reviewed & tested by the community » Needs work

@ #60/nickl: Thanks for writing out your reasoning along with the patch. That helped replying.

It won't fly on multilanguage sites with path prefixing, though.
$prefix is currently used for the language prefix. You're using $prefix for other things... but it seems that the language prefix behaves totally different from 'your prefixes'. So it seems that you should use another variable. (Or put the language prefix in another variable -- whatever you want.)

Behavior with your patch applied:
Say language is 'de'.

1) When viewing the front page, your patch does a drupal_goto('de'). (It used to be drupal_goto(''). ) That's wrong, because drupal_goto() -> url() -> language_url_rewrite() will always add a language prefix itself. (It gets this from global $language.) Therefore you end up going to path 'de/de'.

2) toward the end of your patch, you stripped $prefix out of the comparison. Now $alias is SOMEPATH, while my $_REQUEST['q'] is 'de/SOMEPATH', so the drupal_goto() is always triggered. The code with your patch applied actually creates a redirect loop for me.

In short: in my case (multilanguage with path prefixes; no custom_url_rewrite_* functions defined) the current code works, but your patch breaks things.
Since I don't use PURL or anything, it'd be great if you (or someone) could create/test a patch which leaves the current $prefix behavior alone. I'll test it on my multilanguage site, with and without the #71 code applied.

gaelicWizard’s picture

sub

dhope’s picture

great! Those of us less technically astute will need a volunteering brave soul to apply this badly needed fix to the posted dev version...

zilverdistel’s picture

For my website, the patch in #34 solved the issue of infinite redirection when using a path like url-alias/edit.

Previously I had applied the patch in http://drupal.org/node/744730#comment-3270184, concerning the path_redirect module.

abaddon’s picture

subscribing, and i can confirm as well that #34 works for the stable 6.x-1.2 version, the other patches for the -dev versions do not apply cleanly to the stable release

Shadlington’s picture

Subscribing

splash112’s picture

Subscribing

Dev version works quite ok with i18n, only when I try to open non-translated content (neutral) I get some redirect loops.

http://www.dinilu.eu/product/custom-silicone-bracelet-or-wristband
http://nl.dinilu.eu/product/custom-silicone-bracelet-or-wristband (Dutch, does not work)

edit: now it workds because it's a production site and I switched off Global Redirect

ckng’s picture

#66 GR-6.x-1.x-dev works for me.

Tested with:
Global Redirect 6.x-1.x-dev
Pathauto 6.x-1.5
Sub-path URL Aliases 6.x-1.1
URL alter 6.x-1.2

YK85’s picture

subscribe

jleinenbach’s picture

subscribe

nagiek’s picture

subscribe

jm.federico’s picture

Status: Needs work » Needs review
FileSize
7.18 KB

Ok ppl

Found a solution, some notes:

The problem we have is that both modules keep redirecting and they are both correct in some way. Problem is they both asume they are the boss. First thing I decided was to move globalredirect weight to -50 and make it run before PURL. I want to make sure that we are in the correct URL before anything else happens. With that setting we already solve the redirect problem, but a new one comes to play, there are NO redirects at all when PURL is playing.

The problem is that we are getting a path which Drupal does not know about:
lengauage_prefix/PURL/PATHS/drupal/path
What I did then was check if PURL is installed, and if it is do some corrections to our paths, so that we end up with
lengauage_prefix/drupal/path

This is not what I would call an ideal solution. No module should need to check if there is a different module there unless it is a dependency. But it is a solution nonetheless.
The trick is purl_get_normal_path(), a PURL function that removes PURLS additions. The problem with the original function is that it always returns the aliased path. If we are checking PURL/PATHS/node/1 we get alias/to/node/1

I decided to implement my own purl_get_normal_path() which I called globalredirect_purl_fix(), it does the same as the original but returns the original path we passed on; PURL/PATHS/node/1 would return node/1

I then had issues with the language prefix (damn), I did some twiks for that case.

And finally front page was not working, some more twiks were put in place.

The general idea is:
get PURL's injects out of the way before we proceed.

Now, the ideal solution would be to implement some sort of hook on globalredirect that would allow other modules make corrections to the paths. That way PURL could ship with its own submodule (or we can include it here) that addresses the problem.

The hook should be called everywhere globalredirect_purl_fix is implemented.
Will leave the hook task to you guys.

Cheers

jm.federico’s picture

AH

MAKE SURE YOU CHANGE THE WEIGHT of globalredirect to something lower than -20. Patch is not doing that.

Cheers

jm.federico’s picture

Ladies and everyone else!

New patch, the one in #83 had issues with front paths.

Also, did some code cleanup and added some inline comments.

Remember, you have to set the weight to something lower than -20.

Refer to comment #83 to know what happened here.

przemekz’s picture

subscribe

skolesnyk’s picture

Please commit to the dev release.

nickl’s picture

Status: Needs review » Needs work

Im sorry guys but I don't like the fix suggested in #83 and #85.

Why are we writing a fix for purl specifically when we can just fix global_redirect?
Why duplicate code from purl do we want to maintain purl changes here as well?
I haven't tested but does this fix resolve the issue mentioned by quicksketch in #73, I think not?
What happens if another module implements hook custom_url_rewrite_outbound/inbound which is not compatible with global redirect?
Suggesting the creation of custom global redirect hooks for other modules to also have to write compatibility layers for global redirect will cause an endless downward spiral.
Less code is always better than more code!

I will take some time to test the reasoning behind the suggested patch and also respond to roderick's post in #72 as soon as I can squeeze of some time.

Marking issue as needs work.

jm.federico’s picture

Hello

You're right, we should have as little code as possible, but after spending quite some time trying to find a solution for the PURL problem I ended up giving up on finding a solution not involving either a hook or a check for PURL.

The problem is that PURL is modifying the way Drupal handles URLS by injecting some new elements to the path, which makes it incompatible with Global Redirect, nothing we can do there. It is not Global Redirect faults as I see it, it was just never intended to handle such scenario, and it is just impossible to have a solution that handles every possible case when we don't know what the case is. PURL is just one case, more might come along in the future, thats why I thought a HOOK would give a nice solution, it would let other modules do all sort of crazy as things and integrate with this one nicely.

As for issue in #73, do you mean the multilingual thing? or the issue in #71. Both seem to be fixed with this patch. Didin't know issue #71 would be fixed, didn't test when created the patch, but seems like it does, just tested it. As for multilingual, fully compatible.

roderik’s picture

Trying to clear this up (because I'm also a little anxious about the way this issue is developing):

@ jm.federico: are you saying (in #83, first paragraph) that the patch in #60/66 does not fix 'the PURL problem'? If so, what is the problem with the patch?

That should be made explicit. There have been a couple of people (like #61) who have commented that 'the PURL problem' was fixed for them.

The only reason that this was set to 'needs work' again, is that it messes up i18n (i.e. core functionality). My suggestion to fix that, involves introducing another variable (split $prefix; use both a $prefix and a $lang_prefix variable, because the behavior/logic for purl prefixes is apparently different than for language prefixes). Seems like a small change. The only reason I didn't provide a patch myself, is that I have never used PURL - and this stuff (& my logic of thinking) is more easily tested by people who have more experience with 'funny url rewrite stuff'.

Commenting from the sidelines - it seemed to me like we had a patch already. Which includes less (and more maintainable) code, and does not involve stuff like having to change weights.
So I'm not sure what your patch fixes in a better way.
You may be right in that GlobalRedirect "was never meant to handle such scenario", but... if both PURL and the custom_url_rewrite functions work, after applying a slightly modified #60/#66... I fail to see the need to introduce custom checks/hooks, until we have an actual problem to solve.

@nickl: thanks.

jm.federico’s picture

@roderik
To be honest I didn't try the patch in #60/66. I read on #72 that it wouldn't work on multilingual installs, so I didin't test it myself. My bad. Will test with and without PURL and with and without multilingual and report back.

Cheers

nickl’s picture

If I recall correctly it wast mostly only the trailing slash redirect which caused the redirect loop but my memory is a bit flakey and I will have to dig into this to be sure. Unfortunately I can't seem to get any space to breath at the moment... but I agree with roderik this has gone on far too long. Will do my damnedest to test against i18n as soon as possible.

Tx for your considerations guys, lets nip this one in the bud!

MustangGB’s picture

Been using these patches for a long time now, finally subscribing

scottatdrake’s picture

subscribing

rburgundy’s picture

subscribe

pawel_r’s picture

subscribing

skizzo’s picture

subscribing

mikl’s picture

Assigned: nickl » Unassigned
Status: Needs work » Reviewed & tested by the community
FileSize
3.25 KB

I’ve reformatted the patch by vadym.kononenko from #66, so that it applies to the current Git repository.

I've verified that it works in conjunction with PURL, and as others have already verified that the patch works in the comments above, I am taking the liberty of marking this RTBC.

joelstein’s picture

subscribing.

roderik’s picture

Status: Reviewed & tested by the community » Needs review

@mikl: I have already verified that the patch at #66 doesn't work. Applying this will break multilanguage sites. This is the reason it was set back to 'needs work' in #72, so you can't ignore that.

I have now started using PURL myself, so if nickl doesn't come back to this, I will implement & test a change on a multilanguage site.
(After finally satisfying some clients and getting some money to buy food again, which always seems to take longer than expected ;) ...)

klonos’s picture

Status: Needs review » Reviewed & tested by the community

...would #98 work on multilanguage sites with path prefix though? Are concerns/issues mentioned in #72 handled in this patch?

edit: Roderik got it before I did. Sorry, had that tab open for some time before I actually post the reply :/

roderik’s picture

Status: Reviewed & tested by the community » Needs work

.

djschoone’s picture

#346911-13: Redirect Loop and custom_url_rewrite ignored works for me!

subpath + global redirect went in an infinite loop

frob’s picture

subscribing

venusrising’s picture

Has this gotten any love? The topic is from 2008 and sub path is such a needed feature but the infinite loop is a deal breaker.

splash112’s picture

Was thinking it might be easier to trim the module back to a simple "Global Redirect" module and employ a (or some) hook for i18n, sub_path or others.

venusrising’s picture

@splash112 that would make a great deal of sense. Since it seems like just adding the supported URL for things like user path etc would complete GR.

John Franklin’s picture

subscribing

Manuel Garcia’s picture

Just an update on this issue:

I've digged through the commit log and the patch #34 has been committed to both branches:
http://drupalcode.org/project/globalredirect.git/commit/a41659a (6.x-1.x)
http://drupalcode.org/project/globalredirect.git/commit/9503949 (7.x-1.x, master)

So this is in the latest dev releases.

It's been quite some time since we had a stable release (latest is from 2008-Dec-22) though, so we're stuck having to go to dev.

Manuel Garcia’s picture

There is also a globalredirect 6.x-1.3-alpha1 release. We should probably test that one guys, specially if you have a multilingual site.

Dane Powell’s picture

I know it's not ideal, but it's all that some of us have... so here's #98 rolled against 6.x-1.4.

FYI, my problem was with Open Atrium. When Global Redirect is enabled in an Open Atrium environment, it causes the endless redirect loop when visiting group pages. This patch solves the problem and doesn't have any ill effects that I can tell (but I haven't tested with languages, as mentioned in #100).

venusrising’s picture

Any new updates to the infinite loop issue. Perhaps this should become part of global redirect so the rewrites are more thorough across the site.

wizonesolutions’s picture

Still running into the subpath_alias (latest commit from Git) issue where child paths of aliased nodes (e.g. register/role) direct back to the parent.

Using the latest development version. Maybe I'm barking up the wrong tree.