Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#111 | globalredirect-346911-111.patch | 3.45 KB | Dane Powell |
#98 | 2011-04-06-globalredirect-346911.patch | 3.25 KB | mikl |
#85 | globalredirect-6.x-1.x-dev-346911_85.patch | 6.41 KB | jm.federico |
#83 | globalredirect-6.x-1.x-dev-346911_83.patch | 7.18 KB | jm.federico |
#66 | globalredirect.dev_.2010.08.13.patch | 3.14 KB | vadym.kononenko |
Comments
Comment #1
avolve CreditAttribution: avolve commentedi 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...
Comment #2
WildBill CreditAttribution: WildBill commentedForgive me - what does MAMP stand for?
Comment #3
nicholasThompsonJust as LAMP is "Linux, Apache, MySQL, PHP", MAMP is the same for Mac OS X (Mac, Apache, MySQL, PHP).
Comment #4
nicholasThompsonAs 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.
Comment #6
okokokok CreditAttribution: okokokok commentedI'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?
Comment #7
xaviercas CreditAttribution: xaviercas commentedDrupal 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.
Comment #8
okokokok CreditAttribution: okokokok commentedIt could be related to the web server. I am running nginx. Is anyone running Apache encountering this issue?
Comment #9
Clemens CreditAttribution: Clemens commentedConfirming 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.
Comment #10
WildBill CreditAttribution: WildBill commentedI'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?
Comment #11
xaviercas CreditAttribution: xaviercas commentedDrupal 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.
Comment #12
hongbo CreditAttribution: hongbo commentedI 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
Comment #13
smk-ka CreditAttribution: smk-ka commentedThis 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).
Comment #14
PlayfulWolf CreditAttribution: PlayfulWolf commentedseems that this patch still haven't made to dev version :(
Comment #15
mrfelton CreditAttribution: mrfelton commentedPatch fixes the issue for me (using Sub-path URL), thanks.
Comment #16
phdhiren CreditAttribution: phdhiren commentedthanks smk-ka
I was having problem when Global Redirect and Subdomain modules are together.
Patch in #13 works for me too.
Comment #17
jcmarco CreditAttribution: jcmarco commentedTested and working fine.
I had problems with subpath_alias module and now it works fine.
Comment #18
nicholasThompsonI'll try to commit this patch to 6.x-dev this weekend.
Cheers for all the reviews guys!
Nick
Comment #19
mczenko CreditAttribution: mczenko commentedWorks great ! Thanks !
Comment #20
Steven Jones CreditAttribution: Steven Jones commentedThis 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.
Comment #21
a.a.egoroff CreditAttribution: a.a.egoroff commentedTested 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!!!
Comment #22
jcruz CreditAttribution: jcruz commentedPatch #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
Comment #23
klonosHey 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?
Comment #24
mdih CreditAttribution: mdih commentedPatch #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
Comment #25
dinwath CreditAttribution: dinwath commentedPatch #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!!!
Comment #26
tim.plunkett#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!
Comment #27
xjmApplying 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
Comment #28
lort CreditAttribution: lort commentedpatch 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
Comment #29
BenK CreditAttribution: BenK commentedSubscribing....
Comment #30
crea CreditAttribution: crea commentedsubs
Comment #31
Dave ReidCan someone try with some revised logic that matches how the url rewriting works in D7?
Comment #32
tim.plunkettPatch? 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.
Comment #33
dyke it CreditAttribution: dyke it commentedi 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
Comment #34
doq CreditAttribution: doq commentedCode clean-up.
Comment #35
FiNeX CreditAttribution: FiNeX commentedSubdomain has been patched, does this fix solve the problem reported here?
http://drupal.org/cvs?commit=305572
Comment #36
Dave ReidNo, we still need this committed to Global redirect.
Comment #37
Dave ReidLatest patch looks good to me.
Comment #38
servantleader CreditAttribution: servantleader commented+1
Comment #39
JimmyAx CreditAttribution: JimmyAx commentedPatch at #13 worked great for me.
Comment #40
dashton CreditAttribution: dashton commentedI 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.
Comment #41
popetardo CreditAttribution: popetardo commentedpatch #13 works fine for me too.
drupal 6-15.
Comment #42
nicholasThompsonExellent! Thanks guys - I'll get #13 committed asap! :)
Comment #43
TripleEmcoder CreditAttribution: TripleEmcoder commentedSo when will this be available in dev or a release?
Comment #44
venusrising CreditAttribution: venusrising commentedWhen will this be ready for release. Thanks so much
Comment #45
arski CreditAttribution: arski commentedworks like a charm! can't wait to see it in -dev or, even better, in a release :)
Thanks
Comment #46
AdrianB CreditAttribution: AdrianB commentedSubscribing
Comment #47
Deg CreditAttribution: Deg commentedSubscribing
Comment #48
ralizav CreditAttribution: ralizav commentedThanks!
#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
Comment #49
vzsze CreditAttribution: vzsze commented#13 patch fixes the probleme here. Thank you.
Comment #50
iva2k CreditAttribution: iva2k commentedsubscribe
Comment #51
j0nathan CreditAttribution: j0nathan commentedsubscribing
Comment #52
Dave Reid@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?).
Comment #53
xjmThank you, Dave!
Comment #54
Dave ReidCommitted 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
Comment #56
arski CreditAttribution: arski commentedHey, this is closed already! Any chance of seeing it in a release?
Thanks!
Comment #57
jrearickKind 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?
Comment #58
charlesjc CreditAttribution: charlesjc commentedI too would like to see this rolled up into a release soon.
Please...
Comment #59
tomsm CreditAttribution: tomsm commentedMe too...
Comment #60
nickl CreditAttribution: nickl commentedNot 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.
Comment #61
aufumy CreditAttribution: aufumy commentedglobal 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.
Comment #62
nickl CreditAttribution: nickl commentedThank 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
Comment #63
euchrid9 CreditAttribution: euchrid9 commentedI 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.
Comment #64
awolfey CreditAttribution: awolfey commentedI 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
Comment #65
kekkisSubscribe
Comment #66
vadym.kononenko CreditAttribution: vadym.kononenko commentedI've recreate #60 to the latest DEV.
The loop problem is solved.
Comment #67
TheDoctor CreditAttribution: TheDoctor commentedSubscribed.
Comment #68
TheDoctor CreditAttribution: TheDoctor commentedSame 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.
Comment #69
charlesjc CreditAttribution: charlesjc commentedHi,
I have tested Global Redirect 6.x-1.3-alpha1 with:
All seems OK.
regards,
Charles
Comment #70
Guo CreditAttribution: Guo commentedSubscribing....
#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...
Comment #71
quicksketchJust 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:
Comment #72
roderik@ #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.
Comment #73
gaelicWizard CreditAttribution: gaelicWizard commentedsub
Comment #74
dhope CreditAttribution: dhope commentedgreat! Those of us less technically astute will need a volunteering brave soul to apply this badly needed fix to the posted dev version...
Comment #75
zilverdistel CreditAttribution: zilverdistel commentedFor 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.
Comment #76
abaddon CreditAttribution: abaddon commentedsubscribing, 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
Comment #77
Shadlington CreditAttribution: Shadlington commentedSubscribing
Comment #78
splash112 CreditAttribution: splash112 commentedSubscribing
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
Comment #79
ckng#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
Comment #80
YK85 CreditAttribution: YK85 commentedsubscribe
Comment #81
jleinenbach CreditAttribution: jleinenbach commentedsubscribe
Comment #82
nagiek CreditAttribution: nagiek commentedsubscribe
Comment #83
jm.federico CreditAttribution: jm.federico commentedOk 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 getalias/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 returnnode/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
Comment #84
jm.federico CreditAttribution: jm.federico commentedAH
MAKE SURE YOU CHANGE THE WEIGHT of globalredirect to something lower than -20. Patch is not doing that.
Cheers
Comment #85
jm.federico CreditAttribution: jm.federico commentedLadies 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.
Comment #86
przemekz CreditAttribution: przemekz commentedsubscribe
Comment #87
skolesnyk CreditAttribution: skolesnyk commentedPlease commit to the dev release.
Comment #88
nickl CreditAttribution: nickl commentedIm 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.
Comment #89
jm.federico CreditAttribution: jm.federico commentedHello
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.
Comment #90
roderikTrying 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.
Comment #91
jm.federico CreditAttribution: jm.federico commented@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
Comment #92
nickl CreditAttribution: nickl commentedIf 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!
Comment #93
MustangGB CreditAttribution: MustangGB commentedBeen using these patches for a long time now, finally subscribing
Comment #94
scottatdrake CreditAttribution: scottatdrake commentedsubscribing
Comment #95
rburgundy CreditAttribution: rburgundy commentedsubscribe
Comment #96
pawel_r CreditAttribution: pawel_r commentedsubscribing
Comment #97
skizzo CreditAttribution: skizzo commentedsubscribing
Comment #98
mikl CreditAttribution: mikl commentedI’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.
Comment #99
joelstein CreditAttribution: joelstein commentedsubscribing.
Comment #100
roderik@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 ;) ...)
Comment #101
klonos...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 :/
Comment #102
roderik.
Comment #103
djschoone CreditAttribution: djschoone commented#346911-13: Redirect Loop and custom_url_rewrite ignored works for me!
subpath + global redirect went in an infinite loop
Comment #104
frobsubscribing
Comment #105
venusrising CreditAttribution: venusrising commentedHas 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.
Comment #106
splash112 CreditAttribution: splash112 commentedWas 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.
Comment #107
venusrising CreditAttribution: venusrising commented@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.
Comment #108
John Franklin CreditAttribution: John Franklin commentedsubscribing
Comment #109
Manuel Garcia CreditAttribution: Manuel Garcia commentedJust 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.
Comment #110
Manuel Garcia CreditAttribution: Manuel Garcia commentedThere is also a globalredirect 6.x-1.3-alpha1 release. We should probably test that one guys, specially if you have a multilingual site.
Comment #111
Dane Powell CreditAttribution: Dane Powell commentedI 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).
Comment #112
venusrising CreditAttribution: venusrising commentedAny new updates to the infinite loop issue. Perhaps this should become part of global redirect so the rewrites are more thorough across the site.
Comment #113
wizonesolutionsStill 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.