This is strange combination between drupal core and domain module.
The default language of the default domain gets changed when viewing other domain that has different default language set and when the javascript needs to be rebuild for that language.
The problem was tracked to function _locale_rebuild_js() in includes/locale.inc that when rebuilding the javascript for the language makes this :
$default_langcode = language_default('language');
if ($default_langcode == $language->language) {
$default = db_query("SELECT * FROM {languages} WHERE language = :language", array(':language' => $default_langcode))->fetchObject();
variable_set('language_default', $default);
}
So lets say we have the default domain with default language english. Then the other domain B has default language as danish. When you open domain B and the javascript needs to be rebuild you end up with default language for the domain to be danish and the current language to be danish and therefore the variable value is set to danish and that is wrong. After that if you open the default domain the default language will be danish even if you go to the standard language selection page it will be danish as well as this is the variable value if you check in the table. As there is no other configuration for the default domain all the values are taken from the variables table.
I am not sure that in the default_language situation the variable should be edited. Maybe only global $language should be changed but I am not that deep in the multilanguage options. As far i have added new language variable and used hook_domain_bootstrap_full in my custom module to change the default language and by this ignore the standard drupal settings form but i am not quite sure this is the right way.
Will do more tests and see how this handles.

CommentFileSizeAuthor
#15 1271810-domain-conf-langauge-reset-7x2.patch3.07 KBagentrickard
#14 1271810-domain-conf-langauge-reset.patch3.06 KBagentrickard
#6 da-01.png198.82 KBglobexplorer
#6 da-02.png150.13 KBglobexplorer
#6 da-3.png198.57 KBglobexplorer
#6 da-04.png162.51 KBglobexplorer

Comments

vflirt’s picture

vflirt commented
Title: Default language gets changes » Default language gets changed
Component: Code » - Domain Conf
agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Probably needs to be handled by Domain Locale. Is this only when using JS aggregation?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Active » Postponed (maintainer needs more info)
globexplorer’s picture

globexplorer commented
Priority: Normal » Critical

Exactly the same problem. A complete bug report will follow by tomorrow.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Priority: Critical » Normal

Not critical. Only affects a minority of users.

globexplorer’s picture

globexplorer commented
Issue tags: +domain access, +locale, +default language
StatusFileSize
new da-04.png162.51 KB
new da-3.png198.57 KB
new da-02.png150.13 KB
new da-01.png198.82 KB

Domain Access Version 7.x-2.13
Drupal Version 7.7
i18n installed 7.x-1.0

For the domain access configuration, please refer to the attached screenshots!
As you can see, there are different default languages for some sites.

When somebody views the content on a domain with it's own default language,
and a javascript file has to be updated - Drupal does this when there are new strings that have never been fired - then the default language of the Default (Master) Domain get's changed to the default language of the Domain the JavaScript has been updated.

This goes exactly vflirt has described it!

I marked It as critical, because a JavaScript Workflow manipulates the settings of domain access and language settings -> default language.

I thank you for domain access. It's a cool module. Thank you

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

What does a JavaScript Workflow refer to? Is that a module?

globexplorer’s picture

globexplorer commented

The problematic workflow is this: everytime when Drupal loads a JS file, it looks for Drupal.t()
If this is successful, Drupal checks the default language by a SQL query and performes then an update inside the database - which overrides the default language of the main domain (e.g. "de") with the domain default language (e.g. "hu") of a current page. This leads to a new sitewide default language ("hu"), which is, of course, not intended. That said, domain access, especially domain locale, has to take care of the process of this Drupal core behaviour to avoid this side effect.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Postponed (maintainer needs more info) » Active

Ah. So is this really a Domain Access bug, or a core problem that someone has to work around?

Ideas for how to solve?

globexplorer’s picture

globexplorer commented

Fvlirt says It could be done in implementing hook_domain_bootstrap_full, during hook_enabled. I will try this one. But I think It is a strange behaviour anyway. JavaScript update and boooom. Default language gone. Content disappears. Maybe there is a way to take care of that drupal workflow in overruling the core functions.

But why Fvlirt thinks "hook_domain_bootstrap_full" does a different thing to domain locale?

Thank you anyway for the interaction.

globexplorer’s picture

globexplorer commented

I will try one thing by tomorrow. I will provocate this bug again in adding some new translations. Then I will visit a sub domain where the new translation will set the javascript on fire. Then I will look at the language table to see what has changed.

By tomorrow we've got a solution, I hope.

vflirt’s picture

vflirt commented

Hi,
what i did is kinda of a workaround in my module :

/**
 * Implements hook_domain_bootstrap_full().
 */
function my_module_domain_bootstrap_full($domain) {  
  static $check;
  if ($domain['domain_id'] == 0) {
    
    $table = domain_get_primary_table('variable');
    $my_domain_locale_language = db_query("SELECT value FROM $table WHERE name = 'my_domain_locale_language'")->fetchField();
    if (!empty($my_domain_locale_language)) {
      $my_domain_locale_language = unserialize($my_domain_locale_language);      
      if (!empty($my_domain_locale_language)) {        
        $list = db_query("SELECT * FROM {languages} WHERE language = :language", array(':language' => $my_domain_locale_language))->fetchAllAssoc('language');      
        if (!empty($list[$my_domain_locale_language])) {
          $GLOBALS['language'] = $list[$my_domain_locale_language];
          $conf['language_default'] = $list[$my_domain_locale_language];
        }
      }
    }  
    
    $check = 1;
  }
}

also in hook_domainform in my module I add setting for the language so each domain can set its default language in the edit form.
As for now this is working but as i said in the start not sure if that is ok.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I don't really understand how that code can fix the problem described. It looks very much like the code in domain_conf_domain_bootstrap_full().

Have you tried patching that function?

And why are you being forced to set another variable? Is 'language_default' the issue here?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Version: 7.x-2.13 » 7.x-3.x-dev
Status: Active » Needs review
StatusFileSize
new 1271810-domain-conf-langauge-reset.patch3.06 KB

I am finding this bug very hard to reproduce reliably -- though I have seen it.

The attached patch approach should resolve this issue. It works by watching the functions that call the JS rebuild and then firing a shutdown function to ensure that the primary variable is not altered.

However, I think this might fail in a case where the default language variable has not been expressly saved to the database during configuration.

Needs testing, obviously, by those affected by the behavior.

This patch is against 7.x.3-dev, but should apply to 7.x.2.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
StatusFileSize
new 1271810-domain-conf-langauge-reset-7x2.patch3.07 KB

It does not. Here's a patch against 7.x.2.

globexplorer’s picture

globexplorer commented

You are quicker than me agentrickard! I did your patch, and at the moment It seems that it's working. I will keep my eye on this issue. Thank you!

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

I'd like to roll this into a 7.x.3.1 and a 7.x.2.16 release. Can any else confirm that, at the least, it doesn't make things worse?

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented
Status: Needs review » Fixed

Committing and rolling a new release for testing.

globexplorer’s picture

globexplorer commented

Oh no. It's here again. I patched, but here the error log.

Type locale
Date Tuesday, Dezember 13, 2011 - 19:33
User Anonymous (not verified)
Standort http://hu.leitner.cyledgemedia.com/hu/archive-publications
Referrer
Message Updated JavaScript translation file for the language Hungarian.
Severity notice 


  if ($default_language = domain_conf_default_language()) {
    drupal_register_shutdown_function('domain_conf_set_default_language', $default_language);
  }

But maybe it's not the whole patch. Look at the code snippet from your patch. It sould be $default_language == domain_conf_default_language

Am I right, that you overwrite the default language with the default language saved in the domain_conf table? The problem is both get's changed:

1. admin/config/regional/language
2. admin/structure/domain/batch/language_default

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

The function domain_conf_default_language() is merely a static variable holder, not a lookup to domain_conf. The entire point to the patch was to bypass Domain Conf -- which is not the problem here, the problem is that core resets default language. The = is appropriate, because it the function returns FALSE if nothing is set. Here's the flow:

  1. On page request, we look in {variable} for a 'langauge_default' variable.
  2. If that is present, we store it in static cache.
  3. If the JS rebuild process runs on this page request, we register a shutdown function and pass the contents of the default language variable.
  4. The shutdown function reads the results from step 2 and re-saves them to the {variable} table.

Now, if language_default is not set when this process starts, then I think the error would still occur, because we don't have any data to update (see comment 14 above).

To test, be sure to save the default language form before rebuilding JS (use admin/config/regional/language). It is possible that we aren't properly handling (admin/structure/domain/batch/language_default) as well.

All that said, I haven't been able to reproduce this error consistently.

globexplorer’s picture

globexplorer commented

Ok. I think, well done agentrickard. At the moment everythings fine.

Chicago, Chicago, Chicago that's my home town.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

So is the problem that the default variable wasn't set? If so, we should open another issue to try to work around that (if possible).

globexplorer’s picture

globexplorer commented

Oh god, the problem is still alive. The patch does not solve the problem! The default language get's changed again O:(

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

Please refrain from histrionics in the issue queue.

Let's open a new issue and see if we can trace the new problem. You need to report:

  1. Language settings
  2. Domain-specific language settings
  3. Content of {variable}.language_default
  4. When the error occurs, what actually happens
  5. Steps to reproduce the error
globexplorer’s picture

globexplorer commented

Yes sorry! You are right, but shortly I was in a real trouble, because I'm now on air - live.

# Language settings:

Primary Domain -> DE
Hungary Domain TLD -> HU
Slovakia Domain TLD -> SK
etc.

After I patched the development site, the default language never get's changed again. But then I transfered the dev site, what means I changed my domain names. But of course I did not touch anything else.

Then the first user connected to a sub site eg Hungary. He jumped to a site where a javascript file has included some Drupal.t() strings. Wooom. The default language of the Primary domain, switched to the domain default language of the hungarian site. From DE to HU. Of course the Primary domain doesn't have any content in HU. Therefore the menu's disappeared.

You can see here the Recent log messages. Every time a new user was connected 18:51, 17:56, etc. WOOM.

locale 20.12.2011 - 18:51 Updated JavaScript translation file for the language... Anonymous (not verified)
locale 20.12.2011 - 17:56 Updated JavaScript translation file for the language... Anonymous (not verified)
locale 20.12.2011 - 17:56 Updated JavaScript translation file for the language... Anonymous (not verified)
locale 20.12.2011 - 17:56 Updated JavaScript translation file for the language... Anonymous (not verified)
locale 20.12.2011 - 17:49 Updated JavaScript translation file for the language... Anonymous (not verified)
locale 20.12.2011 - 17:49 Updated JavaScript translation file for the language... Anonymous (not verified)
locale 20.12.2011 - 17:33 Updated JavaScript translation file for the language... Anonymous (not verified)
locale 20.12.2011 - 16:54 Updated JavaScript translation file for the language... admin

Then I did the following. I accessed every page of a domain with a loaded JQUERY file and Drupal.t() functions to get the rebuild_js process to work. After I was sure, that I accessed every page, I changed the default language of the primary domain back to DE. Since then I've never seen this issue again.

agentrickard’s picture

agentrickard
he/him
Primary language English
Location Georgia (US)
commented

What part of "Let's open a new issue" was not clear?

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