I found a pretty insidious bug while writing tests for a large project with 24 languages that has this module enabled.

Currently the following code is executed during hook_boot():

function language_cookie_boot() {
  $method = variable_get('locale_language_negotiation_url_part');
  $languages = language_list('enabled');
  // ...

The problem is that hook_boot() is invoked when Drupal is not yet fully bootstrapped, more specifically at the DRUPAL_BOOTSTRAP_PAGE_HEADER bootstrap phase. In this phase only a very small subset of modules is enabled. The full suite of modules is only enabled when _drupal_bootstrap_full() is called during the DRUPAL_BOOTSTRAP_FULL phase. The Locale module is not among the modules that is enabled at this point.

When you call language_list() now, it will do the following checks:

function language_list($field = 'language') {
  $languages = &drupal_static(__FUNCTION__);
  // Init language list
  if (!isset($languages)) {
    if (drupal_multilingual() || module_exists('locale')) {
      // ...
    }
    else {
      // No locale module, so use the default language only.
      $default = language_default();
      $languages['language'][$default->language] = $default;
    }
    // ...
  }
}

It will check if the Locale module is enabled (which at this point isn't the case), so it will always return the default language only. What's worse is that it will cache the language list statically, basically hosing the output of this function for the remainder of the page load. This causes unexpected behaviour which causes my tests to fail.

The call to module_exists() that happens here also sets a static cache in module_list() which could also cause problems, but this is less problematic since this static cache is reset at the last bootstrap phase.

What is puzzling is that this should always return the default language instead of the full set of languages. I wonder how this could possibly work? I can replicate this by just installing the "standard" core profile and enabling Locale and Language Cookie.

This problem only occurs in the 7.x-1.x branch, not in the 7.x-2.x branch.

Comments

pfrenssen’s picture

Status: Active » Closed (cannot reproduce)

Hmm I retried on a fully clean code base on the latest version of core and I can't replicate this issue any more. For the moment it looks like Language Cookie is not to blame, but rather one of the patches that have been applied to the project. I will pick this back up on Monday, if needed I will reopen the issue.