i18n setup for the Domain Access module
This is a summary of the process of how to setup a multilingual site with domain access. Please feel free to edit any parts which are
The settings for Domain Access are listed on the Domains page (Drupal 7: Administration > Structure > Domains, or http://example.com/admin/structure/domain; Drupal 6: Administer > Build > Domains, or http://example.com/admin/build/domain)
Documentation on this page includes:
These elements define the 'primary' domain for your site. In the event that a user tries to access an invalid domain, this domain will be used.
The primary domain for your site. Typically example.com or www.example.com. Do not use http, slashes or a trailing slash. This domain will be used as the default URL for your site. If an invalid domain is requested, users will be sent to the primary domain.
Enter the primary domain for your site here.
You can also enter this value into settings.php for cookie handling when your domains all share the same base domain (example.com, one.example.com, two.example.com etc).
NOTE: If you have installed Drupal in a subfolder, such as http://example.com/drupal you should not include the folder path as part of the primary domain. Simply use example.com -- Drupal will automatically detect the presence of the subfolder.
NOTE: As of 5.x.1.5 and higher, you may use a port protocol as part of any domain. So you could set example.com:8080 as the primary domain name. Note that port protocols will not be stripped, so that example.com and example.com:8080 are two separate domains.
This value is taken from your system settings and need not be changed. It is provided to allow readability in the domain list.
Allows the site to use 'http' or 'https' as the URL scheme. Default is 'http'. All links and redirects to root site will use the selected scheme.
As noted above, this screen does not register DNS records with Apache.
Use this screen to register new allowed domains with your site. This process is especially important for sites using Wildcard DNS, as it prevents non-registered sites from resolving.
The first domain will use the HTTP_HOST value of the request made when installing the module. This value may be edited by going to Admin > Structure > Domains and editing the Primary Domain value.
The second domain will be given the value test.example.com, where example.com is the Primary Domain value. This domain is set to be 'inactive' initially. You will need to edit this domain record in order to use it.
When you create a new domain record, simply fill in the form:
path.example.com, without http:// or a trailing slash.Both the Domain and the Site name are required to be unique values.
After you create a record, you may edit or delete it as you see fit.
NOTE: As a result of module installation, you will never have a Domain with the domain_id of 1 if you did not use Domain Access prior to 6.x.2.0. This is by design and will not affect the module.
NOTE: When editing a domain record, Domain Access runs an http request to see if the domain is responding properly. This test checks for the presence of the file '200.png' inside the module's 'test' directory.
If a 200 "found" reply is not returned, you will see an message warning you that your DNS may not be configured properly. This message is intended to help you debug your DNS configuration and may be safely ignored.
NOTE: Users who attempt to access an unregistered domain will be redirected to the primary domain automatically.
When creating a domain record, you are restricted to the valid character set for Internet domain names. By design, this includes only the ASCII alphanumeric character set (a-z 0-9) plus the special characters dot (.) dash (-) and colon (:). A colon may only be followed by a port number.
Domains must be lowercase. Domain matching with HTTP_HOST is not case-sensitive.
With the advent of Internationalized Domain Names (IDNs), domain servers are beginning to recognize non-ASCII domain names. To enable support for non-ASCII domain names, you must add the following lines to the bottom of your settings.php file:
// Allow registration of non-ASCII domain strings.
$conf['domain_allow_non_ascii'] = TRUE;
For background, see the following:
If you wish to enforce special business rules for domain name validation, you may implement hook_domain_validate_alter() in your module.
This hook will allow your module to intercept and alter any errors found by the normal domain validation process. See domain.api.php for details.
These options affect the basic options for how the module behaves.
Defines the default behavior for content added to your site. By design, the module automatically assigns all content to the currently active domain. If this value is set to 'Show on all sites,' then all new content will be assigned to all sites in addition to the active domain.
If you set this value to 'Only show on selected sites,' you will be shown configuration options per node type, as described in Send to All Affiliates (below).
This setting presents a list of all active node types on your site. By checking the box, nodes for that given type will automatically be assigned to 'all affiliate sites' during node creation and editing.
This setting is only used if the New Content Settings are set to "Only show on selected sites."
If enabled, this will append node access information to the bottom of each node. This data is only viewable by uses with the 'Set domain access status for all content' privilege. It is provided for debugging, since 'administer nodes' will make all nodes viewable to some users.
When using Node Access modules, user 1 (the super-admin) and users with the 'Bypass content access control' permission are not subject to node access rules. This is a design feature of Drupal, and it can lead to confusion when viewing your site as an administrator.
To help with this confusion, the 'Enforce rules on administrators' setting can be enabled. This setting forces Domain Access rules to be applied even to users who can Bypass content access control.
The default setting is OFF, but if you regularly login as user 1 or a user with the 'Bypass content access control' permission, you may want to enable this feature.
NOTE: This feature only applies Domain Access rules. If you are using multiple node access modules, not all rules will be applied.
Sets a break point for the size of domain lists shown to users. If you have a large number of domains (e.g. more than 20), you may set this value to allow for pagination and truncation of domain lists.
When set to 'Yes', places the Domain options in a vertical tab on the node editing form.
Controls the form element display when choosing a list of domains. By default, Domain Access shows checkboxes, but if your site has a large number of domains, checkboxes hinder usability. You may use this setting to force domain lists to be displayed as multiple select lists instead.
By default, if you have more than 25 domains, a select list will be used for your forms, but you may use this setting to alter that behavior.
This screen shows all active domains registered for use with the site.
From this screen, you may set the default domain, activate or inactivate domains or view to the settings for individual domains.
This is a summary of the process of how to setup a multilingual site with domain access. Please feel free to edit any parts which are