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.
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.
Comments
Comment #1
imoreno CreditAttribution: imoreno commentedSame 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
BR
Itzhak
Comment #2
Vollzeitaffe CreditAttribution: Vollzeitaffe commentedSame here for me. I also switched back to 1.3
Comment #3
pfx CreditAttribution: pfx commentedSame for me
Comment #4
PESTO3567 CreditAttribution: PESTO3567 commentedSAME, it broke my site! Such a nasty Bug shouldn't happen with a stable release.
Comment #5
matthiasm11 CreditAttribution: matthiasm11 at MM-Experience commentedSame 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.
Comment #6
Anjaro CreditAttribution: Anjaro commentedSame 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 ?
Comment #7
matthiasm11 CreditAttribution: matthiasm11 at MM-Experience commentedManually 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,
Matthias
Comment #8
matthiasm11 CreditAttribution: matthiasm11 at MM-Experience commentedManually 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,
Matthias
-- edit: I'm sorry for the double post
Comment #9
syodash CreditAttribution: syodash commentedSame problem here
Comment #10
syodash CreditAttribution: syodash commentedThe solution of matthiasm11 works for me. Whe you delete the global redirect folder all works fine.
Thanks man!
Comment #11
nicholasThompsonDear 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.
Comment #12
nicholasThompsonComment #13
nicholasThompsonThe issue is somewhere around here:
Comment #14
nicholasThompsonHmm actually it seems that in 1.3, the
$prefix
on a french-only site onadmin/config/regional/language
is empty, but in 1.4 it's always fr (regardless of the URL)...Investigation continues....
Comment #15
guenoz CreditAttribution: guenoz commentedSame here
Revert to 1.3
Good luck to fix this ;)
Comment #16
jaiiali CreditAttribution: jaiiali commentedSame problem here
Comment #17
nicholasThompsonOk - turns out 7.x-1.3 worked because it was broken ;)
1.3:
1.4:
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 uselocale_language_url_rewrite_url
. Unfortunately, this has had a negative effect.Now at least I know where to look to fix...
Comment #18
Gunther-1 CreditAttribution: Gunther-1 commentedsame 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!
Comment #19
Jibus CreditAttribution: Jibus commentedThanks 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 !
Comment #20
falcon03 CreditAttribution: falcon03 commentedHi 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?
Comment #21
PROMESI 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!
Comment #22
Anonymous (not verified) CreditAttribution: Anonymous commentedI agree. Please unpublish, if possible. Thank you.
Comment #23
falcon03 CreditAttribution: falcon03 commentedHi 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...
Comment #24
trante CreditAttribution: trante commentedStill i have this error for 7.x-1.4
So i switched back to 7.x-1.3
http://ftp.drupal.org/files/projects/globalredirect-7.x-1.3.tar.gz
I hope this bug will be fixed whenever you release new version.
Comment #25
suryaden CreditAttribution: suryaden commentedsame issue
move back to http://ftp.drupal.org/files/projects/globalredirect-7.x-1.3.tar.gz
Comment #26
angelbreath CreditAttribution: angelbreath commentedSame issue here. Only solution to rollback to 1.3
Comment #27
Tino CreditAttribution: Tino commentedSame 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!
Comment #28
amirtaiar CreditAttribution: amirtaiar commentedMmmmm...
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...
Comment #29
Abilnet CreditAttribution: Abilnet commentedI 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!
Comment #30
nicholasThompsonI'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*
andbatch*
URL's from redirection. This should help in the future.Comment #31
nicholasThompsonI 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.
Comment #32
Jibus CreditAttribution: Jibus commentedHi,
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)
Comment #33
Tino CreditAttribution: Tino commentedThe 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.
Comment #34
nicholasThompsonDamnit....
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)?
Comment #35
Tino CreditAttribution: Tino commentedLanguages: Dutch (enabled, default), English (enabled)
Drupal: 7.10
PHP: 5.3.6
Apache/2
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...
Comment #36
PROMESNicholas, 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.
Comment #37
extrarumeno CreditAttribution: extrarumeno commentedsubscribe
Comment #38
ozon CreditAttribution: ozon commentedI 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).
Comment #39
midmood CreditAttribution: midmood commentedsubscribe
Comment #40
thissideup CreditAttribution: thissideup commentedwell, 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!
Comment #41
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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. :-)
Comment #42
tamsoftware CreditAttribution: tamsoftware commentedsubscribe
Comment #43
nevergone CreditAttribution: nevergone commentedFast workaround:
Comment #44
rogical CreditAttribution: rogical commented+1 my site just crashed by enabling this 'stable' 1.4
Comment #45
Tino CreditAttribution: Tino commentedI 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.
Comment #46
mefisto75 CreditAttribution: mefisto75 commentedSeveral threads pointing to the same problem which seems to be solved with the latest .dev - http://drupal.org/node/1034126
Comment #47
stina CreditAttribution: stina commentedThe 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.
Comment #48
PROMESThe last dev works for me as well.
Thanks.
Comment #49
nicholasThompsonFor 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.
Comment #50
nicholasThompsonAnd 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.
Comment #51
Anonymous (not verified) CreditAttribution: Anonymous commentedNicholas,
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).
Comment #52
pfrenssenI 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:
Language setup in which the problem is NOT fixed:
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()
withdrupal_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 invokelocale_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.
Comment #53
coert CreditAttribution: coert commentedI'm afraid that's not exactly the problem. I have a site which has all that is mentioned:
... 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:
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?
Comment #54
Tino CreditAttribution: Tino commentedI 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. :)
Comment #55
Anonymous (not verified) CreditAttribution: Anonymous commentedThis 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)
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.
Notes for both sites:
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?
Comment #56
pfrenssenTino, 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 :)
Comment #57
Tino CreditAttribution: Tino commentedOnly 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.
Comment #58
dedisoft CreditAttribution: dedisoft commentedTested #55, Site 2 configuration :
All is working now with Global Redirect 1.4.
Comment #59
Daniel Schaefer CreditAttribution: Daniel Schaefer commentedSame issue here for 1.4.
Comment #60
jexperton CreditAttribution: jexperton commentedI 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 :
It works !
Comment #61
Robin Millette CreditAttribution: Robin Millette commentedThought 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!
Comment #62
Robin Millette CreditAttribution: Robin Millette commentedI 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.
Comment #63
pfrenssenMarked #1034126: Infinite loop (error 310) with i18n in D7 as a duplicate of this. Also updating the title.
Comment #64
jisuo CreditAttribution: jisuo commentedGot 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
Comment #65
Jibus CreditAttribution: Jibus commentedTry to remove the language prefix from you default language
Comment #66
milos.kroulik CreditAttribution: milos.kroulik commentedWorks for me, thanks!
Comment #67
vitiok78 CreditAttribution: vitiok78 commentedWorks great! Thanks!
Comment #68
jisuo CreditAttribution: jisuo commentedWhere 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.
Comment #69
Jibus CreditAttribution: Jibus commentedIn admin/config/regional/language, select your default language and remove the language prefixe
Comment #70
jisuo CreditAttribution: jisuo commentedAh edit and then remove it there... somehow I had missed that everytime.
Comment #71
Orkut Murat YılmazI 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:)
Comment #72
jisuo CreditAttribution: jisuo commentedI 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.
Comment #73
Jibus CreditAttribution: Jibus commentedDid you try the dev version ? If it's still not working, I suggest you to rollback to 1.3.
Comment #74
fredfab CreditAttribution: fredfab commentedSame problem, same solution as #71 on my french site.
Many Thanks Nicholas for the dev version !
Comment #75
MaienM CreditAttribution: MaienM commentedWHY is a site-breaking release still up after over a month?
Comment #76
Dropper CreditAttribution: Dropper commentedIt 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?
Comment #77
MrHaroldA CreditAttribution: MrHaroldA commentedUpdating to 1.4 breaks all our multilingual sites.
Where's the 1.5 release?!?
Comment #78
Jibus CreditAttribution: Jibus commentedTry the dev version
Comment #79
MrHaroldA CreditAttribution: MrHaroldA commented@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.
Comment #80
pfrenssenAs 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).
Comment #81
ricferr CreditAttribution: ricferr commentedHi 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
RF
Comment #83
ctapial CreditAttribution: ctapial commentedHello 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.
Thanks.
Comment #84
Mark Theunissen CreditAttribution: Mark Theunissen commentedWe're using the -dev release so far with success. Multilingual site, en is default, 13 languages in total.
Comment #85
OnkelTem CreditAttribution: OnkelTem commentedI confirm, that upgrading to -dev version does solve the issue on my russian website.
Thanks, Nicholas!
Comment #86
pfrenssenI 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.
Comment #87
anouNothing new to add : -dev version solved the problem on french website.
Thanks a lot.
Comment #88
Mark Theunissen CreditAttribution: Mark Theunissen commentedThis version of the module is live on http://icann.org. :)
Comment #89
nevergone CreditAttribution: nevergone commentedRecommended release?
Comment #90
randallknutson CreditAttribution: randallknutson commentedMarked http://drupal.org/node/1476848 as duplicate
Comment #92
triple5 CreditAttribution: triple5 commentedSorry matthiasm, this is not a patch, but just a downgrade ...
this solution has already been described above, besides,- it is not really a solution
Comment #93
rogical CreditAttribution: rogical commentedNo need solution anymore, when all users using Global Redirect ever updated.
Comment #94
marcoka CreditAttribution: marcoka commentedi updated to the dev too and it seems to work so far
Comment #95
paulrooney CreditAttribution: paulrooney commentedSo 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?
Comment #96
fleetcommand CreditAttribution: fleetcommand commentedI'm with paulrooney.
Comment #97
PROMESI agree strongly.
Comment #98
XO-1 CreditAttribution: XO-1 commentedseems to fixed using 7.x-1.x-dev (2011-Dec-30), so I'm with paulrooney
Thanks to nicholasThompson and the rest!
Comment #99
technicalknockout CreditAttribution: technicalknockout commented+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.
Comment #100
Gerto CreditAttribution: Gerto commentedI 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???
Comment #101
Jibus CreditAttribution: Jibus commentedI think, that even if it's a stable version, there can be some problems.
Best way: having a test environnment
Comment #102
technicalknockout CreditAttribution: technicalknockout commentedHaving 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".
Comment #103
gabrielcardon CreditAttribution: gabrielcardon commentedJust 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.
Comment #104
MrHaroldA CreditAttribution: MrHaroldA commented@gabrielcardon
$ 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)! ;)
Comment #105
gabrielcardon CreditAttribution: gabrielcardon commentedWell 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.
Comment #106
plach@nicholasThompson:
LOL
@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?
Comment #107
uno CreditAttribution: uno commentedI 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.
Comment #108
MrHaroldA CreditAttribution: MrHaroldA commentedOk, now we have a real problem. Global redirect 1.3 has a security issue: http://drupal.org/node/1633054
Comment #109
wizonesolutionsOK, 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?
Comment #110
fleetcommand CreditAttribution: fleetcommand commentedOh how nice that we have 1.5 now. Thanks :)
Comment #111
Abilnet CreditAttribution: Abilnet commentedThank you for the release, nicholasThompson & wizonesolutions, your hard work appreciated.
(edit: Added thanks to wizonesolutions as well)
Comment #112
Jibus CreditAttribution: Jibus commentedThanks for you release and your work !
Comment #113
uno CreditAttribution: uno commentedThank you - 7x.1.5 works fine, I had to remove old files, upgrade was not possible.
Comment #114
gabrielcardon CreditAttribution: gabrielcardon commentedThank you very very very much wizonesolutions !
Comment #115
batigol CreditAttribution: batigol commentedGreat job with 1.6 release. I hope Global redirect will merge with Redirect and finally we will have one and elaborated module for seo.
Comment #116
RaulMuroc CreditAttribution: RaulMuroc commentedMaybe suitable to be added in Known Bugs:
A similar problem, perhaps coming from Global Redirect as well can be seen:
http://drupal.org/node/1442822
Thank you.
P.D: I have Global Redirect 1.5 installed and error persists.
Comment #117
RaulMuroc CreditAttribution: RaulMuroc commentedComment #118
ParisLiakos CreditAttribution: ParisLiakos commentedPlease 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