Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Is it possible to set a "domain name" which is different to the "site name"? (i.e. basically give each domain a custom label?)
I have a website for a company with 3 subsidiaries in 4 different countries; I use different domains for each of them, and usually set the "site name" to be the (legal) name of the respective company/subsidiary. In order to make it easier for admins (during content creation) and also users (domain switcher), I would like to label each domain by it's country...
Is this possible somehow? Custom module workarounds would be fine...
Comments
Comment #1
agentrickardUse hook_domain_load() to change the name of the domain if you like. Or use hook_node_form_alter() in a module that runs _after_ domain.
Comment #2
bforchhammer CreditAttribution: bforchhammer commentedHm, if I override the domain name via
hook_domain_load
then the site name is also affected (because it is set indomain_init
)... I'm going to try usinghook_node_form_alter
(and other hooks for other places); was just hoping there might be an easier way ;-)Comment #3
bforchhammer CreditAttribution: bforchhammer commentedI ended up changing the domain name, and overriding
$conf['site_name']
inhook_init()
with custom site names (company names, in my case).Comment #4
agentrickardFor those following along, this will only work if your module's hook_init() fires after domain_init().
Perhaps we should put that alter hook into domain_init()?
Comment #5
bforchhammer CreditAttribution: bforchhammer commentedRight, I have also set the module's weight value to 1 to ensure that that's the case... :-)
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 thesite_name
variable via domain_conf? Or possibly with an option to fall back to the "domain sitename" (enabled by default?).Comment #6
agentrickardThat line is a legacy from the very early days (D5), and I'd hate to remove the behavior now. It does, however, cause issues for i18n folks, so I'd love to get some input.
Comment #7
bforchhammer CreditAttribution: bforchhammer commentedMaybe 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...
Comment #8
agentrickardAs much as I hate adding new setting at this point, we have taken a similar approach to other changes.
My remaining question is: does this allow i18n to act more effectively?
Comment #9
bforchhammer CreditAttribution: bforchhammer commentedI 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.
Comment #10
bforchhammer CreditAttribution: bforchhammer commentedAfter 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).
Comment #11
agentrickardLooks right. We need to whip up a simple test for it.
Comment #12
bforchhammer CreditAttribution: bforchhammer commentedAttached is the same patch with some tests...
Comment #13
bforchhammer CreditAttribution: bforchhammer commentedThis patch will be required for building multilingual site names with the domain_variable module. See also #1593558: Support site_name variable.
Comment #14
lolandese CreditAttribution: lolandese commentedWorks!
Steps followed:
patch -p1 < sitename-override-1550762-12.patch
in /public_html/drupal-7.14/sites/all/modules/domainGoing to admin/structure/domain/view/1/variables I find "Site name: Drupal" and "Site slogan:
<empty>
". I guess this is inevitable for now but a small inconsistency in the UI.Thanks. Great job.
Comment #15
bforchhammer CreditAttribution: bforchhammer commentedNo, 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.
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.
Comment #16
agentrickardSome cleanups here. A few are just text strings. There was some inconsistency in naming. Fixed a form weight issue and an uninstall hook.
Could use a last sanity check. Tests all pass.
Comment #17
bforchhammer CreditAttribution: bforchhammer commentedPatch still applies and looks fine :)
Comment #18
agentrickardCommitted.
8cdd2f7..3975188
Needs a documentation fix: https://drupal.org/node/1096974
Comment #20
dark_kz CreditAttribution: dark_kz commentedTried your manual, but no result http://drupal.org/node/1848864 :(