Posted by marktheshark on November 9, 2011 at 11:53pm
31 followers
| Project: | Global Redirect |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
After enabling a second language (Greek) on my new Drupal 7.9 installation, when saving the new language as the default the site went into a redirect loop (Firefox: "The page isn't redirecting properly" message).
Enabled modules:
- Locale
- Global Redirect [7.x-1.x-dev (2011-May-03)]
- i18n (7.x-1.1)
I am totally unable to access the site now.
Tried disabling Global Redirect and i18n in the DB and by renaming their module directories but to no avail.
Opening against core for initial evaluation, as Global Redirect has already fixed such an issue and I have the same GR version installed on a production site without issue.
Please advise on how I can at least access the site again. Thank you.
Comments
#1
It's a Global Redirect bug, moving to there.
#2
For now to solve your problem quickly. Open globalredirect.module, go to line #218:
<?phpif ($request_path != $prefix . $alias) {
// If it's not just a slash or user has deslash on, redirect
if (str_replace($prefix . $alias, '', $request_path) != '/' || $settings['deslash']) {
drupal_goto($alias, $options, 301);
}
}
?>
and comment this line:
<?phpif ($request_path != $prefix . $alias) {
// If it's not just a slash or user has deslash on, redirect
if (str_replace($prefix . $alias, '', $request_path) != '/' || $settings['deslash']) {
//drupal_goto($alias, $options, 301);
}
}
?>
#3
This patch should make the necessary checking before entering a new redirection loop.
#4
Any chance of this fix getting committed?
Thanks
#5
My Website was also broken because of this Bug. Hope the fix will be committed soon.
#6
Any closer to being reviewed?
#7
thank you good_man, that solved my problem.
#8
This patch should be included in a new release. I had the same issue and, to figure things out I wasted 6 hours and 4 drupal reinstalls. :(
#9
Using the dev version solved that problem.
#10
after enabling global redirect in my new Drupal 7.10 installation, when saving this version module 7.x-1.4
the site went into a redirect loop , I was unable to access the site so I used solution number 2 Posted by good_man
and then I was able to disable Global Redirect , suggestions wellcome
#11
alby111: did you apply the patch?
For other users experiencing that problem:
if you cannot access the site via UI, you can still disable the module using drush.
#12
The patch in #3 does not apply to version 7.x.1.4
error: patch failed: globalredirect.module:216
error: globalredirect.module: patch does not apply
-sh-3.2$ git apply -v 1337132-3.patch
Checking patch globalredirect.module...
error: while searching for:
// Compare the request to the alias. This also works as a 'deslashing'
// agent. If we have a language prefix then prefix the alias
if ($request_path != $prefix . $alias) {
// If it's not just a slash or user has deslash on, redirect
if (str_replace($prefix . $alias, '', $request_path) != '/' || $settings['deslash']) {
drupal_goto($alias, $options, 301);
}
}
error: patch failed: globalredirect.module:216
error: globalredirect.module: patch does not apply
#13
the patch above worked.
#14
@SocialNicheGuru - you said the patch worked. What version of the module did you patch?
Thanks,
Kristen
#15
the latest dev version
#16
I tried to apply to the 1.4 version, so that's probably the cause. Thx for the help.
#17
I can confirm #3 work on latest DEV it solve the problem ! I patch on 6 differents installation and it work.
#18
Several folks have confirmed the patch on dev version.
Kristen
#19
I can confirm that the patch in #3 works. Please, review and possibly commit ASAP.
#20
Patch #3 works fine, I strongly suggest to commit.
#21
@good_man: is $break used later in the code? Why not build it into the second condition or give it a more meaningful name? :)
#22
Patch work great - thanks!
#3 on the latest dev (Dec 30 2011)
Joe
#23
$break is not used later in the code as far as I can tell, so patch needs work. Based upon the number of commenters who claim that it works anyway, probably just means the $break refs can be removed.
#24
My bad, it cannot ofc not be removed, but it should be named something more meaningful, as suggeted in #21.
#25
This thread is still a life-saver! Thank you once more good_man...