I have a language dependent site_frontpage variable and when the front pages are translations of each other this works fine. When you want completely different front pages problems start to arise. Take this example:

node/1 => the-alias (English)
node/2 => the-alias (Dutch and a translation of node/1)
node/3 => another-alias (English)
node/4 => another-alias (Dutch and a translation of node/3)

The default site_frontpage is "the-alias". Through the language_dependent functionality I set the frontpage for the Dutch language to "another-alias". Now everything works fine when I go to http://example.com and http://example.com/nl

However it goes horribly wrong when I visit http://example.com/nl/node/2 (or http://example.com/nl/the-alias). When visiting that url the following happens:

  1. drupal_init_language() removes the language from $_GET['q'] and leaves "node/2".
  2. drupal_init_path() sees that $_GET['q'] isn't empty gets the normal path of "node/2" which is "node/2" and puts that in $_GET['q']
  3. i18n_init() gets the default front page "the-alias", initialises and gets the language dependend front page "another-alias". It also gets the normal path for the normal front page (the-alias) which also happens to be node/2. This makes the i18n module think that the user requested the frontpage for the current langauge and overwrites $_GET['q'] with the path to the node for the new frontpage which causes the incorrect node to be shown.

The issue is that after drupal_init_path has run it is (almost) impossible to detect whether the user requested the front page or a specific node if that node happens to be the front page as well. I've current resolved this issue by setting a global flag in drupal_init_path which resolves my issue. I've attached a path with the modification (the patch is for core and i18n).

Is there any other way to resolve this issue?

CommentFileSizeAuthor
i18n.patch1.16 KBjax

Comments

jax’s picture

I just realise that a quick fix would be to store the node path (node/xyz) in stead of the alias in site_frontpage. The issue with this is that it would be difficult to explain to the customer that he should retrieve the node id before he can set that setting.

jax’s picture

The language switcher block also has issues when the front pages in different languages are different.

function locale_block($op = 'list', $delta = 0) {
  ...
  $path = drupal_is_front_page() ? '<front>' : $_GET['q'];
  ...
}

In my example, if you visit the page the-alias the language switcher block will propose to swith to the frontpage for the Dutch language in stead of the Dutch translation of the the-alias node.

jose reyero’s picture

Status: Needs review » Needs work

About this issue, you can always get the original path from $_REQUEST['q'], so if you could do it without patching core...

jax’s picture

The issue with using $_REQUEST['q'] is that you can't call drupal_init_language() on it and then you are not sure if the front page was requested or not.

The functions drupal_init_language() and language_initialize() should take a path parameter and modify that one in stead of a global one. This way you can call these functions later to check if the front page was requested or not. But that is solved in a much simpler fashion by setting the frontpage flag.

I'll see what I can do without hacking core...

jose reyero’s picture

Status: Needs work » Fixed

This has been reworked in latest versions, and some more issues fixed in -dev, it should work now

Status: Fixed » Closed (fixed)

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

Gill Xu’s picture

+1