Separate domain name and site name

Hm, if I override the domain name via hook_domain_load then the site name is also affected (because it is set in domain_init)... I'm going to try using hook_node_form_alter (and other hooks for other places); was just hoping there might be an easier way ;-)

I ended up changing the domain name, and overriding $conf['site_name'] in hook_init() with custom site names (company names, in my case).

// MYMODULE.module
function MYMODULE_init() {
  global $conf;
  $domain = domain_get_domain();
  drupal_alter('site_name', $conf['site_name'], $domain['machine_name']);
}

// MYMODULE_DE.module
function MYMODULE_DE_site_name_alter(&$name, $domain) {
  if ($domain == 'de_mydomain_com') $name = 'German Company Name';
}

// MYMODULE_CH.module
function MYMODULE_CH_site_name_alter(&$name, $domain) {
  if ($domain == 'ch_mydomain_com') $name = 'Swiss Company Name';
}

this will only work if your module's hook_init() fires after domain_init().

Right, I have also set the module's weight value to 1 to ensure that that's the case... :-)

Perhaps we should put that alter hook into domain_init()?

Sure, why not. Patch attached... (api) docs still missing.

Alternatively I'm wondering whether it might be possible to completely remove that line ( $conf['site_name'] = ...), and expose the site_name variable via domain_conf? Or possibly with an option to fall back to the "domain sitename" (enabled by default?).

Maybe something like this?

Attached patch makes the "sitename overridding" optional, adds a respective checkbox to the module settings page, and adds "site_name" variable into domain_conf forms. For existing users behavior should remain the same...

My remaining question is: does this allow i18n to act more effectively?

I am not sure... I haven't used "i18n + domain" since D6; it's on my agenda for a current project, but it may still be a little while until I get to it. I'm also looking #1307058: Use new Variable API for different variables per domain. on that topic... I guess if the "variable realms" stuff is working then it would also apply to the site_name variable, thus making it easier to translate the site name. Hm.

After working on the domain+i18n+variable integration, I can say: yes, this will definitely help with i18n...

Assuming that a domain_variable module is "the future", anyway. With the override turned off, the sitename is treated like any other variable and can therefore be translated using i18n_variable. Of course, we will still have to solve the domain+i18n variable integration, before it's possible to have proper multilingual sitenames for different domains.

Either way, I think this is a step into the right direction.

Attached is an updated patch... (last one did not remove the site-information form submit handler when the override was disabled).

Attached is the same patch with some tests...

This patch will be required for building multilingual site names with the domain_variable module. See also #1593558: Support site_name variable.

Is site slogan set by default for the domain realm as it's a variable that you probably want to differ between domains?.

No, at the moment no variables are selected by default... you have to enable the slogan manually. We may have to change that eventually, and this will definitely be a required step for #1593548: Migration path from domain_conf.

Going to admin/structure/domain/view/1/variables I find "Site name: Drupal" and "Site slogan: ". I guess this is inevitable for now but a small inconsistency in the UI.

The domain variables page should actually show the same values as set on the site-information form (for the respective domain and active language that is); if that's not the case that's likely a bug in variable_realm or domain_variable... (-> separate issue)

Both issues are independent from this issue+patch.

Patch still applies and looks fine :)