Problem/Motivation

Global Redirect goes into an infinite loop when locale module has been configured to use Path Prefixes.

Proposed Solution

The original issue (patch provided in #9) as well as some followup issues from #10 and #12 have all now been fixed in 7.x-1.x-dev branch.

Remaining tasks

None. This is already committed and fixed! I wrote this summary because I missed comment #25 explaining that this had been committed and fixed because people hijacked the thread and kept subscribing. :)

This bug reoccurs in the 7.x-1.4 release.

Original report by lnunesbr

This module crashed my drupal 7 installation with internationalization. It goes to a infinity recursive redirect.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Bright Web Design’s picture

Priority: Normal » Critical
FileSize
12.49 KB

Same for me too. I use i18n with multiple languages and it produces this error or message site is not accessible. Site is accessible only through the default language.

Please see the attached screen shot.

SebCorbin’s picture

Title: Not working with i18n in D7 » Infinite loop (error 310) with i18n in D7

Changing title & subscribing

danmccarey’s picture

subscribing

rayfun’s picture

same here.. subscribing

amalaer’s picture

same here.. subscribing

luckystrikerin’s picture

subscribing

mjgruta’s picture

This also happens to me.

When Global Redirect enabled:
website.com/en/page <- problem
website.com/page <- OK

nico059’s picture

Same problem here ... the correction:
globalredirect.module: line 82 and 87
I think, in D7 ... language_url_rewrite should be replaced by locale_language_url_rewrite_url
In my case this resolve the infinite loop ... no extensive test done yet ...

Thx nicholas for your module and your time contributed to Drupal ;-)
... excuse my quick post ... I'm in a rush ...

SebCorbin’s picture

Assigned: Unassigned » SebCorbin
Status: Active » Needs review
FileSize
834 bytes

nico059 was right, here's a patch

mjgruta’s picture

Thanks this works! and I think Global redirect fixes my problems on Views for not showing default language if no translation available.
also remember if you are using Views don't forget to add Filter: Node translation: Language -> Current user's language because Views->Query Settings->Field Language-> Current user's language is not working(I think so).

Some Problems:
and when I enable Language Path Checking I get this problem on a Page with a Views Block.

* Notice: Use of undefined constant LANGUAGE_NEGOTIATION_NONE - assumed 'LANGUAGE_NEGOTIATION_NONE' in globalredirect_init() (line 145 of F:\Web Development File\www\drupal7\sites\all\modules\globalredirect\globalredirect.module).

* Notice: Use of undefined constant LANGUAGE_NEGOTIATION_PATH_DEFAULT - assumed 'LANGUAGE_NEGOTIATION_PATH_DEFAULT' in globalredirect_init() (line 146 of F:\Web Development File\www\drupal7\sites\all\modules\globalredirect\globalredirect.module).

* Notice: Use of undefined constant LANGUAGE_NEGOTIATION_PATH - assumed 'LANGUAGE_NEGOTIATION_PATH' in globalredirect_init() (line 147 of F:\Web Development File\www\drupal7\sites\all\modules\globalredirect\globalredirect.module).

* Notice: Use of undefined constant LANGUAGE_NEGOTIATION_DOMAIN - assumed 'LANGUAGE_NEGOTIATION_DOMAIN' in globalredirect_init() (line 167 of F:\Web Development File\www\drupal7\sites\all\modules\globalredirect\globalredirect.module).

luckystrikerin’s picture

I have the same prob with the Language Path Checking. Additionally after applying the patch I can't uncheck URL detection any more. This would let to strange redirects like sitename/.../en/en/.../.../en/xyz.

albertosilva’s picture

FileSize
850 bytes

The problem with LANGUAGE_NEGOTIATION_* is that all those variables come from Drupal 6, and are not present in Drupal 7.

I have a patch for "globalredirect.module", it works perfect so it maybe could help you.

tsvenson’s picture

Status: Needs review » Reviewed & tested by the community

Brilliant, the patch got rid of the errors for me.

Marty2081’s picture

Patch works for me. Thanks!

metalinspired’s picture

Worked for me too. Thank you

mjgruta’s picture

The patch worked but global redirect is not really working with i18n as of now.

Dave Reid’s picture

Status: Reviewed & tested by the community » Needs work

Please post a patch using diff -u

Dave Reid’s picture

Version: 7.x-1.3 » 7.x-1.x-dev

Please also post your patch against 7.x-1.x branch, not the 7.x-1.3 release as some of the patch has already been applied.

Cray Flatline’s picture

subscribimg

dmsmidt’s picture

sub

mikl’s picture

Maybe the solution for #346911: Redirect Loop and custom_url_rewrite ignored could be of help here?

lathan’s picture

sub

FiNeX’s picture

Patch on #12 works fine :-) Thanks!

Daemon_Byte’s picture

subscribe

nicholasThompson’s picture

Status: Needs work » Fixed

I have committed the fixes from #12 into 7.x-1.x-dev. I have also added several SimpleTest rule to ensure redirection is acting sensibly.

cronix’s picture

Any idea when this will result in a new "stable" release?

tovetsky’s picture

Hi all,

I can confirm that the problem still exists under the following scenario:

Internationalization 7.x-1.0-beta5
Global Redirect 7.x-1.3

Fix #8 above from nico 059 got me out of the infinite loop. 2 lines need to be edited. The one that checks if the function exists and the one that executes the function. Both lines in 'globalredirect.module' need to be changed to 'locale_language_url_rewrite_url'. Here's the block of code.

  // 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);
  }

Thank you nico059

Status: Fixed » Closed (fixed)

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

floown’s picture

@tovetsky : I have apply your patch, it does not work now with : Global Redirect 7.x-1.x-dev (2011-May-03) and I18n 7.x-1.0-beta7…

tahiticlic’s picture

subscribe

giupenni’s picture

subscribe

camdarley’s picture

Status: Closed (fixed) » Active

subscribe, same config than floown and patch from tovetsky not working

daften’s picture

subscribe

ASupinski’s picture

I ran into this issue, or something remarkably similar and found that my problem was that drupal_get_path_alias will return the original path if there is no alias. If this path already contains the language prefix then the existing global_redirect check if ($request_path != $prefix . $alias) will always be true causing the loop. I believe the attached simple patch resolves this issue.

irishdan’s picture

subscribe

DamienMcKenna’s picture

Should I write "+1" or "Subscribe"? Hrm... Oh, wait.

DamienMcKenna’s picture

Status: Active » Fixed

Marking this ticket as Fixed again as the new issue is unrelated to the original topic. Please open a new issue referencing this one if needed.

Status: Fixed » Closed (fixed)

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

erasoft’s picture

Hi, I got the same error... What should I do with this patch?

DamienMcKenna’s picture

Status: Closed (fixed) » Needs work

The patch from #34 needs work, it doesn't follow the Drupal coding standards.

DamienMcKenna’s picture

Status: Needs work » Needs review
FileSize
676 bytes

I've cleaned up the patch from #34.

FYI please check the documentation on how to apply patches.

j.somers’s picture

subscribe

I also want to note that the patch attached to #1034126-41: Infinite loop (error 310) with i18n in D7 did not work for me. However, the patch attached to #774950-7: Incompatible with hook_url_inbound_alter() did solve this in my case.

SebCorbin’s picture

Assigned: SebCorbin » Unassigned
icetristar’s picture

robphillips’s picture

None of the patches above seemed to work for me. Using the latest stable versions of globalredirect and i18n I modified globalredirect.module to recognize when i18n is present. I tested this thoroughly and it enabled full translation support. Feel free to modify and/or put into a patch file.

globalredirect.module, lines 217 to 231

  // Load current langcode from i18n module.
  if (function_exists('i18n_langcode')) {
    if ($current_langcode = i18n_langcode()) {
      $langcode_replacement = $current_langcode .'/';
    }
  }

  // Compare the request to the alias. This also works as a 'deslashing'
  // agent. If we have a language prefix then prefix the alias
  if (str_replace($langcode_replacement, '', $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);
    }
  }
patrick mbongo’s picture

Hi ! i try to use global redirect (the latest dev version ) but it not working with multilingual multisite drupal installation....in the other subdomain site it generate url like this
"http://mysite.com/it/it/it/it/it/it/it/it/it/it/it/it/it/it/"(italian is default language but it the same with the other languages ) .solution?
thanks

matthiasm11’s picture

The code of post #1034126-45: Infinite loop (error 310) with i18n in D7 works almost fine.
(applied to the globalredirect.module, stable version 1.3)

This goes fine:
mysite.com/title-of-my-node (should redirect to mysite.com/nl/title-of-my-node, because nl is my default language?)
mysite.com/nl/node/25 turns into mysite.com/nl/titel (nl = dutch language, "titel" is dutch for title)
mysite.com/fr/node/8 turns into mysite.com/fr/titre (fr = french, "titre" is french for title)
mysite.com/admin

This goes wrong:
mysite.com/node/25 -> 301 loop
mysite.com/nl -> 301 loop
mysite.com/fr -> 301 loop
mysite.com/nl/admin -> 301 loop
mysite.com/fr/admin -> 301 loop
mysite.com/nl/node/8 turns into mysite.com/nl/titre (= french node showed with a dutch prefix but french title in the url -> should redirected to mysite.com/fr/titre)
mysite.com/fr/node/25 turns into mysite.com/fr/titel (= dutch node showed with a french prefix but dutch title in the url -> should be redirected to mysite.com/nl/titel)

Some changes in the code of post #1034126-45: Infinite loop (error 310) with i18n in D7 could possibly fix this?

Kind regards,
Matthias

berdyshev’s picture

FileSize
1.83 KB

yes, changes from comment #45 work, but the same changes must to be introduced for front page
here is patch, that works for me. please review it.

matthiasm11’s picture

Thnx BerdArt!
Your patch solved the 301 loops.

These redirections shoud be updated:
mysite.com/nl/node/8 -> no redirect (= French node showed with a Dutch prefix and node_id in the url -> should redirected to mysite.com/fr/titre)
mysite.com/fr/node/25 -> no redirect (= Dutch node showed with a French prefix and node_id in the url -> should be redirected to mysite.com/nl/titel)
mysite.com/title-of-my-node should be redirected to mysite.com/nl/title-of-my-node, because nl is my default language, so there aren't 2 urls for the same content. (search engine optimalizaton - sandboxed)

Any fixes?

Kind regards,
Matthias

piepkrak’s picture

subscribe

mattez’s picture

Last DEV version globalredirect 7.x-1.x-dev (updated: May 3, 2011 - 00:11) FIX this issue for me.

iAugur’s picture

Last DEV version globalredirect 7.x-1.x-dev (updated: May 3, 2011 - 00:11) Fixed this issue for me too (D7-commerce-multilingual site)

bartvdputte’s picture

Last DEV version globalredirect 7.x-1.x-dev (updated: May 3, 2011 - 00:11) FIX this issue for me.
Use the DEV version, it'll fix this issue.

Status: Needs review » Needs work

The last submitted patch, fix_infinite_loop.patch, failed testing.

rickmanelius’s picture

Status: Needs work » Fixed

Patch not necessary as it's committed to dev and it works for me, #51, #52, and #53. Marking as fixed.

Summit’s picture

Hi,

Dev of 3 december 2011 is not good enough, patch 48 was still necessary for me,
So I had to add patches:
http://drupal.org/node/1034126#comment-4078848, http://drupal.org/node/1034126#comment-4848778 and http://drupal.org/node/1034126#comment-5102720

I think now it is working with i18n.
Greetings, Martijn

khiminrm’s picture

Status: Fixed » Active

The same error in Dev version from 24 november, 2011

Meller’s picture

had the same problem, version globalredirect-7.x-1.x-dev solved it for me.

torbjoernk’s picture

Dev tarball from 2011-Nov-24 fixed this issue for me in combination with D7.10 and i18n 7.x-1.2. Thank you for fixing :)

typoagrafka’s picture

subscribing

checker’s picture

In my case i got it fixed with unsetting a prefix for default language. Only for non-default languages you need a prefix. (global redirect dev 2011-Nov-24)

nicholasThompson’s picture

FYI, Patch #12 made it into the 1.4 release.

This needs some more work as I'm not very familiar with i18n...

javizcaino’s picture

I have updated today to version number 1.4 and the problem is still there...

I'm affraid I'll have to remove this module from my installation...

FlowerOS’s picture

Version: 7.x-1.x-dev » 7.x-1.4

Problem reappeared after upgrade to 7.x-1.4

checker’s picture

@javizcaino @FlowerOS please can you tell us your language and negotiation settings?

axe312’s picture

I have the exact same problem. My default language is "de", "en" is also active and i have the default settings of all modules (fresh installation). I also have i10n_update installed. Maybe this causes the problem.

checker’s picture

@axe312
did you try to remove path prefix "de" under "admin/config/regional/language/edit/de"? I guess you don't need it because its your default language.

Satri’s picture

Similar problem after updating from 1.3 to 1.4. I got a redirect loop in the form of:
interactiveweather.ca/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr/fr

Note that the only language-related modules I use on that site are: I10n_update and transliteration.

Hope this helps. - Alex

trante’s picture

subscribe

FlowerOS’s picture

Site is "ro" and this is the default language on site.

sa3er’s picture

The same problem here as in #68
http://mysite.com/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/fa/...

English is also active but the default language is Persian.
had to downgrade to 7.x-1.3

javizcaino’s picture

@checker, my language negotiation is "Default - Use default site language (Spanish)"

hgmartini’s picture

As in #68, I just had the same issue after updating to 7.x-1.4. It was working fine with 7.x-1.3. In my case, all pages get redirected to /en/en/en/...

The only language detection methods enabled are "User" and "Default" (default is Spanish) and enabled languages are es and en. I'm using l10n_client 7.x-1.0, l10n_updates 7.x-1.0-beta2, i18n* 7.x-1.2.
I guess it redirects to /en because my environment and browser settings are English, although "Browser" language detection is disabled in Drupal.

For now I'll have to go back to 1.3.

Please tell me if there's something else I can do to help solve this.

ronny89’s picture

scito’s picture

My infinite redirections are gone with the lastest dev version. i18n and globalredirect are working for me. I'm just using the latest globalredirect dev version, no additional patches.

Thanks for your job!

scito’s picture

Issue summary: View changes

Created a summary to let people know this is already fixed!

TipiT’s picture

Confirmed. Latest dev (7.x-1.x-dev) fixed the problem. Thank you!

AdamGerthel’s picture

Confirmed here too. Seems to work well

cateye’s picture

Is there a chance for a new release with this fix?

pfrenssen’s picture

Status: Active » Closed (duplicate)

This is actually an old issue which has been fixed a long time ago (see comment #25).

The redirection loop is occurring again in the latest release, but this may have a different cause since the original problem had been fixed. The problem is now being tracked in #1378690: Update to 7.x-1.4 adds duplicate language prefixes, causing a redirection loop. I'm going to mark this as a duplicate since the other issue has more current test reports.

Please mind that the problem has *not* been fully fixed in the latest dev. The problem is fixed only with certain language negotiation configurations but still occurs with other configurations. This probably will also need some tests before a new release can be made.

XO-1’s picture

Another confirm, though site is still in testing, problem seems to be solved after the install of the 7.x-1.x-dev.
P.S. if it is any help to other newbies: i just went to the sites>all>modules>globalredirect folder. Deleted all the files in that folder, and replaced with the unzipped files from the 7.x-1.x-dev download.

Special thanks to nicholasThompson and everybody else for all your effort on fixing this problem.

Final request: can somebody make it more clear that 7.x-1.4 is not the best choice for downloading right now? It does not mention that very clearly on de globalredirect download page right now.

I am so #@$#$ relieved that my site is accessible again... hahaha :P

pfrenssen’s picture

@XO, this is already mentioned on the project page, look under "Known bugs" ;)

pfrenssen’s picture

Issue summary: View changes

Updated remaining tasks

  • Commit a4015d2 on 7.x-1.x, master, 8.x-1.x by nicholasThompson:
    #1034126 - Applying patch from asilgag to fix language negotiaion in...
efpapado’s picture

Hi, there are several tasks concerning an infinite loop that is caused when Language Path Checking is enabled, and I think the issue queue needs a cleanup.

Current dev version seems to still have the same problem.
My setup: Two active languages, and the default does not have a prefix (blank value). Enabling Language Path Checking causes infinite redirect loop error.

I propose a patch. I have only tested it with my setup, and it seems to work, but I don't know if it's going to work on different setups.

efpapado’s picture

Version: 7.x-1.4 » 7.x-1.x-dev
Status: Closed (duplicate) » Needs review

Changing status and version.

albertosilva’s picture

Chris Matthews’s picture

Status: Needs review » Closed (outdated)

@efpapado, if your comments in #83 are still relevant you'll probably need to open another issue.