I just updated the module from 7.x-1.3 to 7.x-1.4 and i noticed that the the prefix of my current language was always added to the url (/fr/).

I do not use i18n module, i have just the french pack translation.

Removing the language code from the default language (/config/regional/language) resolved the issue.


imoreno’s picture

Same over here site is broken, all URL's was www.mysite.co.il/he/he/he/he/he/he/he/he/he/he/he/he

I had to revert back to 7.1.3


Vollzeitaffe’s picture

Same here for me. I also switched back to 1.3

pfx’s picture

Same for me

dotmagic’s picture

SAME, it broke my site! Such a nasty Bug shouldn't happen with a stable release.

matthiasm11’s picture

Same issue.
This happend to me on my single language site: www.mysite.com/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl, so i switched back to 7.x-1.3. On my multilangual site, 7.x-1.4 works fine.

Anjaro’s picture

Same thing with a danish site, "da" is added to the links.
Where do you find the 1.3 for download ? so i can switch back ?

matthiasm11’s picture

Manually remove the content of the directory "sites/all/modules/global redirect".
Extract the files of this zip into the empty folder: http://ftp.drupal.org/files/projects/globalredirect-7.x-1.3.zip

Kind regards,

matthiasm11’s picture

Manually remove the content of the directory "sites/all/modules/global redirect".
Extract the files of this zip into the empty folder: http://ftp.drupal.org/files/projects/globalredirect-7.x-1.3.zip

Kind regards,

-- edit: I'm sorry for the double post

syodash’s picture

Same problem here

syodash’s picture

The solution of matthiasm11 works for me. Whe you delete the global redirect folder all works fine.

Thanks man!

nicholasThompson’s picture

Dear god - how did THAT get through all the tests. I'll be adding a test for a site which only uses one non-english language for future protection.

Working on fixing this now.

nicholasThompson’s picture

Priority: Normal » Critical
nicholasThompson’s picture

The issue is somewhere around here:

214   // Compare the request to the alias. This also works as a 'deslashing'
215   // agent. If we have a language prefix then prefix the alias
216   if ($request_path != $prefix . $alias) {
217     // If it's not just a slash or user has deslash on, redirect
218     if (str_replace($prefix . $alias, '', $request_path) != '/' || $settings['deslash']) {
219       globalredirect_goto($alias, $options);
220     }
221   }

nicholasThompson’s picture

Hmm actually it seems that in 1.3, the $prefix on a french-only site on admin/config/regional/language is empty, but in 1.4 it's always fr (regardless of the URL)...

Investigation continues....

guenoz’s picture

Same here

Revert to 1.3

Good luck to fix this ;)

jaiiali’s picture

Same problem here

nicholasThompson’s picture

Ok - turns out 7.x-1.3 worked because it was broken ;)


  // Let the language_url_rewrite do it's magic, if preset.
  // TODO: Is this needed anymore?
  if (function_exists('language_url_rewrite')) {
    // Note 1 : the language_url_rewrite() takes path (by reference) as the
    //          first argument but does not use it at all
    // Note 2 : We use $request_path here as we want the path in an untouched
    //          form (current_path() gets modified by core)
    language_url_rewrite($request_path, $options);
  $prefix = rtrim($options['prefix'], '/');


  // Let the locale_language_url_rewrite_url() do it's magic, if preset.
  // TODO: Is this needed anymore?
  if (function_exists('locale_language_url_rewrite_url')) {
    // Note 1 : the locale_language_url_rewrite_url() takes path (by reference)
    //          as the first argument but does not use it at all
    // Note 2 : We use $request_path here as we want the path in an untouched
    //          form (current_path() gets modified by core)
    locale_language_url_rewrite_url($request_path, $options);
  $prefix = rtrim($options['prefix'], '/');

In 1.3, we looked for language_url_rewrite which is a legacy D6 command (wasn't caught during the port from 6 to 7). This was fixed in 1.4 to use locale_language_url_rewrite_url. Unfortunately, this has had a negative effect.

Now at least I know where to look to fix...

Gunther’s picture

same problem here for dutch (nl)

since you can't reach the site because of 'too many redirects' error, solution of matthiasm11 was necessary
good luck on fixing this!

Jibus’s picture

Thanks for your quick answer nicholasThompson !

I am not an expert, but the prefix is needed only for multilingual site, right ? And not for single language site ?

Maybe it need to add a condition to verify if the module internationalization (or translation) exist ? (module_exists('internationalization)

Anyway, thanks for this great module !

falcon03’s picture

Hi all,
same problem here...
I was going crazy because my site wasn't working!
So, what I could do to fix this problem?
The unique fix for this is to downgrade to 1.3 version?

PROMES’s picture

I have the same problem. But WHY can I still download this buggy release at this moment after all these posts. It should be removed before more people and sites get into trouble!

genox’s picture

I agree. Please unpublish, if possible. Thank you.

falcon03’s picture

Hi all,
I have to report good news! :-)
Maybe I found a workaround...
Before enabling the global redirect module, I went to the language edit page (site.com/admin/config/language/edit/your_language) and deleted the "language prefix" (i don't know the exact string, I am using drupal localized into Italian).
When I enabled the module I saw it worked...
Now I am testing how it works, but it seems a workaround... :-)
What about you? Maybe a possible fix to post on the module page?

Sorry for my bad English, I am a 17 year old Italian student...

trante’s picture

Still i have this error for 7.x-1.4
So i switched back to 7.x-1.3

I hope this bug will be fixed whenever you release new version.

suryaden’s picture

angelbreath’s picture

Same issue here. Only solution to rollback to 1.3

Tino’s picture

Same problem here. Been searching for hours why D7 websites kept returning 301 ERR_TOO_MANY_REDIRECTS.
Removing the global redirect module brought the site back up. So also rolling back to 1.3.
To avoid headaches for other Drupal users, I suggest to quickly remove 1.4.
Nevertheless, thanks for all the hard work on this handy module!

amirtaiar’s picture

I have the same issue, so I have rool back to 1.3 and the issue appears again!
I have 2 language - It's happen only on the English ones - domain.com/en...

I was wonder wether I should do this - http://drupal.org/node/1337132#comment-5226978 as I am afraid of breaking my site...

Abilnet’s picture

I also found this problem. Solution is to downgrade to some previous version (in my case 1.3)

Sorry I'm not able to help fixing the bug, but I'll be happy to help by testing.

Thanks for your hard work!

nicholasThompson’s picture

I'm still working on this. For some reason, I can no longer replicate this on my local dev box. Strange...

I have added a feature to the D6 and D7 dev branches which protects the admin* and batch* URL's from redirection. This should help in the future.

nicholasThompson’s picture

I can no longer replicate this issue with the dev branch. Could someone please try the 7.x-1.x dev release (not on a production site!) to see if it helps?

One thing I have found is that the configuration of the host running SimpleTest has an effect on the results of the test. A "Clean" Drupal install passes the Global Redirect language test 100%, however if I install some language packs, configure them and give them all prefixes - the tests start to fail. I think most of the failures are, however, due to unexpected results rather than major errors.

Jibus’s picture


Working for me (english site with french translation pack).

EDIT: i spoke too quickly, the problem remain in the front office (back-office is now OK)

Tino’s picture

The 7.x-dev version of today does not solve the issue.
The site on which I tested is not really multilingual site. English is still enabled though, besides Dutch (deafult), on admin/config/regional/language/overview.

nicholasThompson’s picture


Jibus - yeah the admin section should be ok/protected now. I have committed a fix to D6/D7 branch to stop GlobalRedirect effecting the admin area.

Tino - what exactly is your configuration? English (enabled?) + Dutch (enabled & default)? Are you getting the repeating language prefix issue? What are you running version-wise (Drupal, Apache, PHP, etc)?

Tino’s picture

Languages: Dutch (enabled, default), English (enabled)
Drupal: 7.10
PHP: 5.3.6

This perticular website is hosted in a subdomain.
Result of 7.x-1.4 and 7.x-dev = http://new.website.nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl/nl...

PROMES’s picture

Nicholas, I also have a D7 site with Dutch enabled + default (English is of course enabled but not in use), without any prefix in use => the default installation for a non-English language.
My website, still in building stage, runs on a local pc with WAMP.
The URL is: localhost\newsite.

extrarumeno’s picture


ozon’s picture

I have the same problem. First, I disabled the module using drush. I disabled English on admin/config/regional/language, then everything works fine (only german is active).

midmood’s picture


thissideup’s picture

well, the fix from #1337132: Redirect loop after enabling second language and setting it to default almost works, it only adds one language indicator.

now since I do not use a multi-language setup, this still breaks my site, but maybe is another starting point?

oh and, I highly suggest reverting to 1.3 on the project page for a stable release. having drupal sites with other languages as english as default is not that peculiar and if we want to or not: there are production sites that do not test updates!

genox’s picture

I agree with #40 - please do not publish 1.4 as a "stable release" when it's clear that there's a critical bug in this release! There are really a lot of sites with a multi-lingual setup out there and the bug doesn't just spit out a couple of php errors - it goes "boom". ;-)

The fact that a broken release (ok, only part of the demographic will ever experience it, but it's not a small part ..) stays up and marked as "stable" for more than 3 weeks already is a bit frightening, actually. If a module is installed on ~ 75'000 sites, you have to make sure that the "stable" release really is "stable" and - if necessary, revert. Not to say that users shouldn't "test before deploy" but still. If you try to install a module and it makes your site go haywire, the user experience is really not that great. :-)

tamsoftware’s picture


nevergone’s picture

Fast workaround:

  1. Database backup.
  2. Put site into maintenance mode: admin/config/development/maintenance
  3. Disable Global Redirect module
  4. Go to „Languages” page: admin/config/regional/language and edit default language
  5. Delete „Path prefix language code” (quote: „For the default language, this value may be left blank.”) and save
  6. Enable Global Redirect module
  7. If site is correct, disable maintenance mode
  8. Hooray!
rogical’s picture

+1 my site just crashed by enabling this 'stable' 1.4

Tino’s picture

I suggest urgent action in this matter. Maybe it's an idea to post version 7.x-1.3 again as 7.x-1.5 in the meantime. Too many sites are going down and in my case it took a while to find out that this module was causing it and before I found this thread. I am probably not the only one, there are probably thousands of sites using this handy module.
Especially since updating is so much more user friendly in Drupal 7.x, an update of a module like this should be a safe and easy affair imho.

mefisto75’s picture

Several threads pointing to the same problem which seems to be solved with the latest .dev - http://drupal.org/node/1034126

stina’s picture

The workaround on #43 posted by nevergone worked for me! I'm working on a french site that will only be in french. I don't know if this will work for multilingual sites.

PROMES’s picture

The last dev works for me as well.

nicholasThompson’s picture

For all those who suggest unpublishing the release - I personally dont think that'll help. I'd rather focus my efforts on helping to get a decent stable 1.5 out.

The difficulty *I* have is that:
a) I cannot replicate this on my local VM anymore
b) I don't maintain any multilingual sites
c) There are reports that -dev fixes it.

If more people can confirm -dev fixes it, I'll tag that and get it out. The last thing I wanna do it tag a new release only for the bug to still exist.

nicholasThompson’s picture

And on a personal note, to people posting comments like genox did in #41...

1) I maintain this module mostly in my own spare time for free. I spent my evenings on this outside of my paid work time.
2) I don't release things unless I *believe* they are stable. I have a lot of Unit tests in place and before deploying I ran them several times. They always returned 100% green. Obviously, I'm not gonna think "oh well, it's only multilingual sites it doesn't work on - doesn't matter to me..."
3) As mentioned above, I do not have any production sites to test this on personally, this makes it harder to get releases tested.
4) It's very disheartening/demotivating to hear those kinds of comments. In the time it was written, something positive/contributive could have been written to help us progress to solve the problem. Instead the choice was made to criticize work and effort made by someone who wasn't paid to do it and only chose to do it to help the community.

Sorry for that rant - but it's not pleasant when people decide to be negative in a community which is built on sharing helping each other.

genox’s picture


Please accept my apologies. It is not my intent to criticize your work or the time you invest. I appreciate the work every single module maintainer does, by heart. Maybe this didn't got thru very well in my post but suggesting to roll back was meant to a) reduce the amount of confusion for everyone who ends up with a broken site, b) reduce the amount of posts about "it breaks my site", thus reducing the amount of fragmentation resulting from hopping from one thread to the other for the maintainers, explaining the same thing ten times and taking the heat from all those who end up criticizing.. etc.

Of course I don't think that you'd ever release knowing that it breaks it. I've got multiple multi language sites online (2 to 5 languages, D6 and D7) and I'm offering you to test dev releases on the staged sites, just drop me a note whenever you want me to run a test.

Please don't take this personal. :-)

ed. 7.x-1.x-dev works spot on (with/without language prefixes and/or subdomains).

pfrenssen’s picture

Title: Update to 7.x-1.4 adds duplicate language prefixes, causing a redirection loop » Update from 7.x-1.3 to 7.x-1.4 always add the language prefixe to the url
Issue tags: -Needs tests

Update 2012/03/02:

Please disregard this report. I further investigated this today and it was actually caused by an issue in Strongarm (#1062452: strongarm_set_conf() needs to be called sooner).

I have been doing some testing with an affected site. I can confirm that on this site the problem exists with 7.x-1.4 but not with 7.x-1.x. However when I change the language negotiation the problem reoccurs. Mind that the setup that is in use in this website is actually broken: it has english enabled, not as the default language, without prefix. This is against the instructions that only default languages can have no prefix. I have updated globalredirect on many multilingual sites but this issue only affects one of them: the one with the broken setup. Possibly this bug only affects sites which have a bad multilingual setup to begin with.

Language setup in which the problem is fixed in 7.x-1.x:

  • admin/config/regional/language
    • Dutch: enabled, default language, prefix 'nl'
    • English: enabled, no prefix
  • admin/config/regional/language/configure
    • Only "Default"

Language setup in which the problem is NOT fixed:

  • admin/config/regional/language
    • Dutch: enabled, default language, prefix 'nl'
    • English: enabled, no prefix
  • admin/config/regional/language/configure
    • Both "URL" and "Default"

I have used git bisect to pinpoint the commit that solved the problem in language setup #1: 572087f. It appears that exchanging locale_language_url_rewrite_url() with drupal_alter('url_outbound'); was the solution.

However there is bad news. It seems like this appears to work only because of a bug that has been introduced in this commit. In my site the only hook that fires is locale_url_outbound_alter(). However the documentation mentions "Most commonly this will be used to invoke locale_language_url_rewrite_url().". Either the code or the documentation is wrong here.

Anyway the problem is not fixed. If I simply enable the "URL" detection in the language negotiation settings (see language setup #2) the infinite redirect is back.

During testing I noticed some very strange behaviour in this site even with globalredirect turned off. If I set a prefix for both languages and enable URL detection I get 404's for all pages in the default language. I have not tested if this problem already occurred before globalredirect was updated or if it is caused by the broken language setup.

coert’s picture

I'm afraid that's not exactly the problem. I have a site which has all that is mentioned:

  • admin/config/regional/language
    • Dutch: enabled, default language, prefix 'nl'
    • English: enabled, prefix 'en'
  • admin/config/regional/language/configure
    • Only "Default"

... and 7.x-1.4 doesn't work for me. This bug only gets fixed when I disable English and effectively have only one site, OR if I remove the prefix for the default language ('nl' in this case) ending up with this:

  • admin/config/regional/language
    • Dutch: enabled, default language, no prefix
    • English: enabled, prefix 'en'
  • admin/config/regional/language/configure
    • Only "Default"

So to me it seems that it's not the case that only default languages can have no prefix, actually it seems to me that default languages may not have a prefix.

Anyway, removing the prefix from the default language fixes this in multilingual setup, can anyone confirm this?

Tino’s picture

I can also confirm that 7.x-1.x-dev of 2011-Dec-30 does not have this issue anymore (dev of 2011-Dec-29 still did). It works fine now!
Switching default languages doesn't break it either.

Drupal: 7.10 - Dutch (enabled, default), English (enabled)

Nicholas, thanks again for your respected work!

I never meant to be disrepectful or unthankful in my comments. My sincere apologies if I ever implied otherwise. I was also merely looking for a way to avoid frustations for other Drupal users and admins who update modules on their website. In many cases they will be updating more modules at the same time. In my case it wasn't easy or trivial to pinpoint the issue at hand to this module in the first place.

Rolling back to 7.x-1.3 seemed to be the easiest, fastest and most pragmatic solution for maintainer and users in my opinion. Hence my suggestion. I considered the time to figure out a way to come up with a more permanent fix, without (potential) crashes breathing in our necks, to be more relaxed. :)

genox’s picture

This is what I can report using the latest -dev version of this module:

Site 1: Does only have content of 1 language, since it is "virtually multilingual", as in english is only there because it's Drupal's default. Therefore, there is no language prefix used on any pages *normally* and the user effectively cannot change the language. However, the "eternal redirect" happened on those kind of multilingual setups too with Global Redirect 1.4. (ed: it effectively does not use "language neutral" content)

  • admin/config/regional/language:
    • de: active, default, prefix "de" (top of the list)
    • en: active, prefix "en"
  • admin/config/regional/language/configure
    • "Default", active, bottom of the list
    • other language negotiation modes are disabled

Site 2: Uses specific content for every language and has pretty much every i18n feature enabled in every content type. Prefixes work as expected, even with Global Redirect 1.4.

  • admin/config/regional/language:
    • de: active, default, prefix "de" (top of the list)
    • fr: active, prefix "fr"
    • it: active, prefix "it"
    • en: active, prefix "en"
  • admin/config/regional/language/configure
    • URL, active, default (top of the list)
    • "Default", active, (second mode, fallback)
    • other language negotiation modes are disabled

Notes for both sites:

  • Global Redirect is effectively using default configuration values on both sites. Never touched that.
  • Path Auto patterns are pretty simple and not language specific.
  • I have about 5 Sites with the same setup like Site 1 above. All of them go haywire with 1.4 but not with the latest -dev. BUT when enabling "URL" as a negotiation mode on admin/config/regional/language/configure, the endless redirect stops and everything works fine. The problem only exists if "URL" is not selected as a negotiation mode. All other modes do not seem to affect the behavior.
  • I have about 3 Sites with the same setup like Site 2 above. All of them work with both 1.4 and the latest -dev.

edit: As stated below, this seems to be rather odd. I cannot explain that, really. :-P

Maybe it has something to do with the priorities of language negotiation modes? Or wether your site's content items effectively are language specific or just language neutral? I just figured that even if I only use one language, I always set a language per content item - never "language neutral". This is done by configuring a content type to always be of language "default". To make it easier to add translations later on.

Maybe this is a starting point, if content items are language neutral or not. Otherwise, I have not even the smallest idea where to look for this. :-(

Is there a way we can log something that could help the maintainer? Is it possible to log something somewhere, this early in the bootstrap? Any ideas?

pfrenssen’s picture

Tino, can you post your language negotiation settings, and test if your site still works if you change these? I'd like to know if you are having the same issue as me. If I enable the "URL detection" the problem is back, even with the latest 7.x-1.x.

Edit: Genox reports the exact opposite behaviour, interesting :)

Tino’s picture

Only default is enabled.
URL, Session, User and Browser are not enabled on admin/config/regional/language/configure if that's what you mean.
I only keep English installed so I can easily switch language in case I need to search drupal.org for issues that might arise. When you only have dutch admin menus, it is sometimes difficult to look for the right words. I do not have any real multilingual D7 sites live to test this yet.

dedisoft’s picture

Tested #55, Site 2 configuration :

All is working now with Global Redirect 1.4.

Daniel Schaefer’s picture

Same issue here for 1.4.

Jiho’s picture

I had same troubles when i updated Global Redirect, so i downgraded it.
But troubles came back when i activated language detection by prefix (even with Global Redirect 1.3)

I fixed it when i updated to 1.4 and activated language detection by prefix at the same time :

  1. Don't active any language detection method
  2. Set the URL detection method on prefix (prefix/domaine page)
  3. Open the language detection method page (URL/Session/User/Browser/Default page)
  4. Update Global Redirect to 1.4
  5. Go back to the step 3 page, check URL method and submit form

It works !
Sorry for my broken English.

Robin Millette’s picture

Thought I'd chime in.

1.4 works fine for me. Two languages, FR (no lang. prefix) and EN (en lang. prefix). FR is default. Select by URL prefix. I have i18n and a plethora of submodules enabled, but no other redirect modules (in i18n or otherwise). I enabled variable translation and I use it for the front_page variable. It's set to node/1 in french, node/5 in english. Every redirection works like expected. In globalredirect settings, I enabled Frontpage Redirect Handler and Language Path Checking. It's all perfect I'm happy to say!

Robin Millette’s picture

I noticed, but haven't debugged yet, a problem with node without a translation, but with a language set. If node/5 is a new French node, but I ask for en/node/5, then I get infinite redirections. When there is a translation (say, node/6 in English) for it, asking for en/node/5 redirects us to en/node/6. Path aliases are also followed.

pfrenssen’s picture

Title: Update from 7.x-1.3 to 7.x-1.4 always add the language prefixe to the url » Update to 7.x-1.4 adds duplicate language prefixes, causing a redirection loop

Marked #1034126: Infinite loop (error 310) with i18n in D7 as a duplicate of this. Also updating the title.

jisuo’s picture

Got this problem today with 1.4 version.

1) Installed new fresh site.
2) English was the only and default language.
3) Added Swedish.
4) Made it default.
5) BOOM! Error 310

Jibus’s picture

Try to remove the language prefix from you default language

milos.kroulik’s picture

Try to remove the language prefix from you default language

Works for me, thanks!

vitiok78’s picture

Works great! Thanks!

jisuo’s picture

Try to remove the language prefix from you default language

Where do you do that?

In admin/config/regional/language/configure I can only activate for all?

Also this problem happens with 1.3 as well for me.

Jibus’s picture

In admin/config/regional/language, select your default language and remove the language prefixe

jisuo’s picture

Ah edit and then remove it there... somehow I had missed that everytime.

Orkut Murat Yılmaz’s picture

I have installed globalredirect-7.x-1.x-dev (Release Date: 2011-Dec-30) and it has worked in my Turkish website. Thanks for the dev release:)

jisuo’s picture

I had the problem again.

1) I added a new language.
2) On that new language I can't remove the prefix since only the default language can remove the prefix.
3) So I make it default.
4) Too many redirects...

So I can never remove the prefix since I get the redirect error before I get the chance to remove the prefix...... moment 22.

I have to disable the module in the db, then use drush to cache clear all, then remove the prefix, then enable the module again.

Jibus’s picture

Did you try the dev version ? If it's still not working, I suggest you to rollback to 1.3.

fredfab’s picture

Same problem, same solution as #71 on my french site.
Many Thanks Nicholas for the dev version !

MaienM’s picture

WHY is a site-breaking release still up after over a month?

Dropper’s picture

It just broke my site and I had a hard time trying to figure out how to solve this problem. Why is a module marked as stable when it is breaking sites?

MrHaroldA’s picture

Updating to 1.4 breaks all our multilingual sites.

Where's the 1.5 release?!?

Jibus’s picture

Try the dev version

MrHaroldA’s picture

@Jibus: testing as we speak, but it's a real shame this critical bug seems to be solved, but unreleased.

The 1.4 version is borked and thus unstable.

pfrenssen’s picture

Title: Update from 7.x-1.3 to 7.x-1.4 always add the language prefixe to the url » Update to 7.x-1.4 adds duplicate language prefixes, causing a redirection loop
Issue tags: +Needs tests

As I mentioned above in this issue the latest dev version does not solve the problem completely and is not ready for release. Also this will need some automated tests to prevent this from happening in the future.

Update 2012/03/02: the problem I was experiencing was actually caused by an issue in Strongarm (#1062452: strongarm_set_conf() needs to be called sooner).

ricferr’s picture

Issue tags: +Needs tests

Hi all,
I had the same problem with portuguese. I tried to add that language and the site went down, getting a lot of wrong redirects (en/en/en/en...) even before setting the portuguese language as default.
My problem was that I have the site almost finished and only now decide to add the portuguese language to translate some words in the interface. I could detect which module was causing this and could access the admin pages to delete the recently added language. Just before panicking, I fond this thread which saved my evening.
As soon as I replaced the 1.4 by the 1.3 version, all was working fine.
Thanks for all the contributions

ctapial’s picture

Hello everyone.

I encountered the same problem in my site. It's English (enabled) and Spanish (enabled, default). I didn't have the module installed before. I fresh installed the 1.4 version and the site broke down, the module kept attaching /en to the url.

After reading the whole thread I installed the dev release and the problem was fixed.


Mark Theunissen’s picture

We're using the -dev release so far with success. Multilingual site, en is default, 13 languages in total.

OnkelTem’s picture

I confirm, that upgrading to -dev version does solve the issue on my russian website.

Thanks, Nicholas!

pfrenssen’s picture

Version: 7.x-1.4 » 7.x-1.x-dev
Status: Active » Fixed
Issue tags: -Needs tests

I was the only person having reservations about this being fixed in the latest development version. I found out that the redirect loop I was experiencing in one single case was actually caused by a problem in the Strongarm module. I can now also confirm the issue to be fixed in the latest dev. Considering the large number of confirmations I assume we can safely mark this as fixed.

anou’s picture

Nothing new to add : -dev version solved the problem on french website.
Thanks a lot.

Mark Theunissen’s picture

This version of the module is live on http://icann.org. :)

nevergone’s picture

Recommended release?

randallknutson’s picture

Marked http://drupal.org/node/1476848 as duplicate

Status: Fixed » Closed (fixed)

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

triple5’s picture

Sorry matthiasm, this is not a patch, but just a downgrade ...
this solution has already been described above, besides,- it is not really a solution

rogical’s picture

No need solution anymore, when all users using Global Redirect ever updated.

marcoka’s picture

i updated to the dev too and it seems to work so far

paulrooney’s picture

So if this is broken in 7.x-1.4 (2011-Dec-21), but fixed in 7.x-1.x-dev (2011-Dec-30), perhaps 7.x-1.5 should be released?

fleetcommand’s picture

I'm with paulrooney.

PROMES’s picture

I agree strongly.

XO’s picture

seems to fixed using 7.x-1.x-dev (2011-Dec-30), so I'm with paulrooney
Thanks to nicholasThompson and the rest!

technicalknockout’s picture

+1 on a new release and thank you to the developers and everyone contributing.

Sorry if this sounds like a rant, but I think waiting to release this fix hurts Drupal's user experience reputation. The community works very hard to make great software, but this is one of those things that makes things more difficult than they need to be for end-users.

Today a D7 site with global redirect module prompts users to update to a version with a known critical issue, while there is a known fix - please find your inner steve jobs and think of how great it is when you open and install shiny new software that just works.

Gerto’s picture

I cannot believe after so many months this is still present in the STABLE version.
I updated my site yesterday and this broke the entire site.

Yes, installing dev version solved it just like for everyone else, but please release a new stable version then.
I know this is all free and you are doing this voluntarily, but an issue that breaks a complete site is still remaining after 6 months???

Jibus’s picture

I think, that even if it's a stable version, there can be some problems.

Best way: having a test environnment

technicalknockout’s picture

Having multiple environments to test and stage websites is something developers do - the whole point of a CMS is to have people that cannot code or don't have a clue about basic sysadmin tasks publish on the web. Non-technical people are already confused just by the process of upgrading a module. I'm pretty sure these people will try wordpress or joomla before they start learning programmer "best practices".

gabrielcardon’s picture

Just broke my entire website.
I don't what the argument is for not updating the stable version since it clearly isn't, I mean stable.

On a multi-language website you basically have to kill the whole thing reinstall and load backup B4 install of this module (when you have one).
Therefore calling the 7.x-1.4 a stable version is complete nonsense.

Can somebody give me a good alternative for SEO and Sitemap tools that would not make use of Global Redirect ?
I will not rely on this, there's a big difference between a module bug that fires an error and a module bug that breaks the whole thing.

Ho, and thanks for the lecture on multiple environments, that's uber smart.

MrHaroldA’s picture


$ drush dl globalredirect-7.x-1.3

... no need for backups when you have drush!

I'd also like to lecture you about using DTAP-environments for your site(s)! ;)

gabrielcardon’s picture

Well I'm new to Drupal, to UNIX, to ssh, I just googled DTAP and Drush.
You have to be obviously very smart and good (and patient) to master it all. And I hope to do.

But still :

I see a recommended, highlighted in green, version of a module that has been breaking websites for 6 month and has generated over 100 messages.
There's been a fix for 6 month as well, and that is to install the dev, highlighted in red, version of the module.

I have a basic understanding of traffic lights, I would modify the colors codes, it is a bit confusing for conscientious drivers as it is.

plach’s picture


I have a basic understanding of traffic lights, I would modify the colors codes, it is a bit confusing for conscientious drivers as it is.


@gabrielcardon (and others suggesting this) is right, although things might have been put a little bit kinder. It would be nice to have a stable release including this fix. Is there any plan or roadmap about it?

uno’s picture

I understand that this module should be considered as a gift to community (and I am a gracefull user too), but situation like these does not help Drupal.

Recently Drupal Update started to inform that dev is obsolete and it should be replaced by 7.14. Luckily for me, after having previous loop problem with "stable" module, I do not dare to upgrade prior to exensive testing on a local site, but there would certainly be a number of users who will proceed with update and break their sites.

I can imagine their frustrations and I cannot understand why is 7.14 still considerred as stable, since it is stable only for exclusively English sites.

MrHaroldA’s picture

Ok, now we have a real problem. Global redirect 1.3 has a security issue: http://drupal.org/node/1633054

Versions affected
Global Redirect 6.x-1.x versions prior to 6.x-1.4.
Global Redirect 7.x-1.x versions prior to 7.x-1.4.


Install the latest version:

If you use the Global Redirect module for Drupal 6.x, upgrade to Global Redirect 6.x-1.4
If you use the Global Redirect module for Drupal 7.x, upgrade to Global Redirect 7.x-1.4

wizonesolutions’s picture

OK, I'm just coming in here. New co-maintainer and want to make sure everything is good. So far I know we need 7.x-1.5 released. Is 6.x all good? This issue only affected 7.x, right?

fleetcommand’s picture

Oh how nice that we have 1.5 now. Thanks :)

Abilnet’s picture

Thank you for the release, nicholasThompson & wizonesolutions, your hard work appreciated.

(edit: Added thanks to wizonesolutions as well)

Jibus’s picture

Thanks for you release and your work !

uno’s picture

Thank you - 7x.1.5 works fine, I had to remove old files, upgrade was not possible.

gabrielcardon’s picture

Thank you very very very much wizonesolutions !

batigol’s picture

Great job with 1.6 release. I hope Global redirect will merge with Redirect and finally we will have one and elaborated module for seo.

RaulMuroc’s picture

Maybe suitable to be added in Known Bugs:

A similar problem, perhaps coming from Global Redirect as well can be seen:


Thank you.

P.D: I have Global Redirect 1.5 installed and error persists.

RaulMuroc’s picture

Status: Closed (fixed) » Active
ParisLiakos’s picture

Status: Active » Closed (fixed)

Please open a new issue.Most likely there is a problem with your configurations..it cant be fixed for 100+ followers here, but not you ;)
lets keep this issue dead