Domain language negotiation broken when a base url is configured

Created on 29 October 2012, about 12 years ago
Updated 28 August 2023, about 1 year ago

It would appear there is a use-case where the function locale_language_url_rewrite_url() produces an improper URL.

When working with domain specific (LOCALE_LANGUAGE_NEGOTIATION_URL_DOMAIN) URLs for language negotiation which are nested in subdirectories, so for instance, if we have drupal rendering behind something like this:

we run into a problem if the locale modules setting for USER INTERFACE TEXT LANGUAGE DETECTION method is enabled for URL.

Due to a hardcoding of the base url within the function locale_language_url_rewrite_url(), these lines...

$host = 'http://' . str_replace(array('http://', 'https://'), '', $options['language']->domain);
$host = parse_url($host, PHP_URL_HOST);

// Apply the appropriate protocol to the URL.
$options['base_url'] = $url_scheme . $host;

...which dictate what the new base_url shall be, are overwriting the URL path. Should the site be using the global setting $base_url, the value is ignored, the paths are forced to render incorrectly and the rest of the site will generate HREF from the base HOST url and send the user in the wrong direction when navigating links.

The following edit to locale.inc corrects this and ensures the global value is used:

// Let's check the $base_url and add it to the path if it exists.
global $base_url;
if (isset($base_url)) {
  $base_path = parse_url($base_url, PHP_URL_PATH);
  if ($base_path) {
    $options['base_url'] .= $base_path;
  }
}

I've included a patch file in case this can make it upstream.

Hopefully you find this useful and compelling to help solve a fringe use-case.

🐛 Bug report
Status

Needs review

Version

7.0 ⚰️

Component
Language system 

Last updated about 7 hours ago

  • Maintained by
  • 🇩🇪Germany @sun
Created by

🇨🇦Canada wilco

Live updates comments and jobs are added and updated live.
  • Needs manual testing

    The change/bugfix cannot be fully demonstrated by automated testing, and thus requires manual testing in a variety of environments.

  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • D8MI

    (Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024