Allow language domain to be overridden in settings.php

I've encountered the same problem. When I deployed my code from production to a development environment, I kept getting redirected to production. I added the following code to fix the issue, but I'm trying to find the best place to put it..

<?php
$language_default = variable_get('language_default','');
if ($language_default->domain != 'http://' . $_SERVER['HTTP_HOST']) {
  $language_default->domain = 'http://' . $_SERVER['HTTP_HOST'];
  variable_set('language_default', $language_default);
}
?>

You can't do variable overrides in settings.php or with Drush. This is because these domain settings are put in the "languages" table; they are not Drupal variables. You could stick the above code in settings.php, but it's a bit of a hack. What really needs to happen is have core support these settings as variables that can be overridden.

Until that happens, I'd recommend adding Drush commands such as these to your deployment processes.

drush @site-alias sqlq "UPDATE languages SET domain = 'fr-language-domain' WHERE language = 'fr'"
drush @site-alias sqlq "UPDATE languages SET domain = 'en-language-domain' WHERE language = 'en'"
drush @site-alias cc 'all'

...after you move your DB to whichever site (dev, staging, etc.).

• "site-alias" is the Drush alias for the site you've just deployed to.
• "XX-language-domain" is the actual domain setting.
• And the two-letter language code is the language that you're setting.

This is all in core now. Adjusting issue settings as appropriate.

Subscribing.

The site alias feature (the sites/sites.php file) is precisely designed for this type of things. Could someone check if it can be used this way?

Subscribing.

Subscribing (and tagging as potential edge case for a possible SettingsAPI).

Another solution for Guys scenario:

Tested on:
Drupal 6.2
Drush 4

When running drush sql-sync, I used the --skip-tables-key provided to exclude tables from being tranferred. This leaves the dev languages table variables as their original desired values.

Example Source: example.drushrc.php

$options['skip-tables'] = array(
'common' => array('cache', 'cache_filter', 'cache_menu', 'cache_page', 'history', 'languages', 'sessions', 'watchdog'),
);

Script:

drush sql-sync @live @dev --skip-tables-key=common

subscribe

@howiek03: I'd recommend being careful with that approach. If you upgrade Drupal on @dev, and the schema changes for the "languages" table, this change won't get propogated to @live because the table is skipped. Even if you run updatedb, the schema version pointer in the @live DB will say it's up-to-date, when that table isn't.

I'm actually using this approach to not overwrite Webform tables on @live, but this a contrib module, where each of them maintains its own schema version pointer. You can then update the code, run updatedb and then do the sql-sync. This won't work for core though, as it's already partially updated, so I'd avoid it.

@colan, I considered that when deciding which method to use (updates vs skip). I still opted for skip. At some point I might pay the price, but I am aware ahead of time.

After reading the above I decided to go with Colan (#3) and turn his commands to a bash-function.

The code:

#!/bin/bash
function fix-lang (){
if [ $1 ]
then
  if [ $1 = "live" ]
  then
    drush @$1 sqlq "UPDATE drp_languages SET domain = 'http://en.example.com' WHERE language = 'en'"
    echo "ENGLISH FIXED"
    drush @$1 sqlq "UPDATE drp_languages SET domain = 'http://el.example.com' WHERE language = 'el'"
    echo "GREEK FIXED"
    drush @$1 cc 'all'
    echo "ALL DONE"
  elif [ $1 != "live" ]
  then
      drush @$1 sqlq "UPDATE drp_languages SET domain = 'http://en.$1.example.com' WHERE language = 'en'"
      echo "ENGLISH FIXED"
      drush @$1 sqlq "UPDATE drp_languages SET domain = 'http://el.$1.example.com' WHERE language = 'el'"
      echo "GREEK FIXED"
      drush @$1 cc 'all'
      echo "ALL DONE"
  fi
else
  echo "No site specified"
fi
}

Drush aliases and subdomains should be the same in order for the above to work. For example @stage should be stage.example.com and @staging should be staging.example.com and @live should be the live site (example.com)!
As you can see the urls are hardcoded inside the function. I don't find this a problem because I have a different cpanel account for every site so I can change this function for each of my clients.

I suppose urls could be set as parameters, it might be good but it I believe could become tedius to write the url every time.

I hope somebody will enjoy the above code!

subscribing

The site alias feature (the sites/sites.php file) is precisely designed for this type of things. Could someone check if it can be used this way?

I just looked into it. It cannot be used this way. It can only be used for mapping site aliases to site directories. See example.sites.php for details.

Can someone tell what the status is for Drupal 8?
Can a language domainname be overridden from settings.php?

It can be overridden through config overrides.

Party!

Currently it's a pain each time manually editing my db with a local import.
Good te hear this is gone.

If this works for Drupal 8 but not for 7, could that feature be backported?

There is a module for this for D7: https://drupal.org/project/language_domains

That module looks very cool

To add an example snippet of what you need to put in your settings.php or settings.local.php:

$config['language.negotiation']['url']['domains']['en'] = 'my-en-url.localhost';
$config['language.negotiation']['url']['domains']['de'] = 'my-de-url.localhost';
$config['language.negotiation']['url']['domains']['es'] = 'my-es-url.localhost';
$config['language.negotiation']['url']['domains']['fr'] = 'my-fr-url.localhost';