Skip to main content

Drupal: Multi-site and Signing-in once

With Drupal a developer has many different choices in order to help him create a multi-site installation.

First of all, we should clarify what needs we have. We might need different modules in each site, but we might, also, need different themes, different names and nothing else. We might need to create affiliate sites with one common sign-in. All this can be done with drupal.

The drupal way (without using any modules) is to create different folders under the sites folder. The installation already contains sites/all and sites/default. By creating folders below:
1. sites/all/modules
2. sites/all/themes
3. sites/default/modules
4. sites/default/themes
5. sites/example
6. sites/example/modules
7. sites/example/themes
we allow drupal to associate different (sub)domains with the same installation but with different modules and enabled.

Under sites/all/modules and sites/all/themes are placed the modules and themes that will be available to all (sub)domains. In contrary, under sites/default/modules and sites/default/themes drupal recognises modules and themes available for installation only in default installation. The same goes for example as well.

If we create subdomains, and not different domains, if we want to allow users to sign-in once for all subdomains, we must set the $cookie_domain variable in settings.php to .example.com. Be careful at the first dot!
Another way to create something like above, is to use the module DomainAccess. It comes with many other modules and has the ability to associate the sites/default folder to different (sub)domain names. All it does is create different tables for each (sub)domain in the same database whenever the administrator chooses.

For example, let's say we want to create www.example.com and sub.example.com. We want both to have their content available to both sites but the permissions for each site to be different. All we have to do is copy the permissions table from the primary site www.example.com for sub.example.com to find it. And this is done of course from the modules' drupal administration page. No programming skills required.

Another possibility is that we have different webservers, with different drupal installations, associated with different domains, installed in different databases, using the same database server(ex. 192.xxx.x.1 and MySQL). Even in this case, a user can sign-in only once to all sites. Using the SingleSignOn module including the SSO controller and SSO client modules. This module can be used even with different domains. It needs a primary domain to be set, like DomainAccess does, but the session id stored in database by the controller domain, is recognised by all client domains.

What will be used for each project is something totally chosen by the developer. The table below tries to simplify things a bit:
  Users sign-in once for all sites Users sign-in for every different site
Domain with one or more subdomain(s)
(only one drupal installation)
or
(only one webserver installation)
  • drupal way(no modules)
    • use $cookie_domain
  • Domain Access module
    • use $cookie_domain
  • drupal way(no modules)
    • don't use $cookie_domain
  • Domain Access module
    • don't use $cookie_domain
  • Domain with one or more subdomain(s)
    (many drupal installations)
  • drupal way(no modules)
    • use $cookie_domain
  • Domain Access module
    • use $cookie_domain
  • drupal way(no modules)
    • don't use $cookie_domain
  • Domain Access module
    • don't use $cookie_domain
  • One or more domains with zero or more subdomains
    (only one drupal installation)
    or
    (only one webserver installation)
  • drupal way(no modules)
    • use SSO modules
  • Domain Access module
    • use SSO modules
  • drupal way(no modules)
    • don't use SSO modules
  • Domain Access module
    • don't use SSO modules
  • One or more domains with zero or more subdomains
    (many webservers)
    and/or
    (many drupal installations)
  • use SSO modules in each installation
  • don't use SSO modules at all
  • One or more domains with zero or more subdomains
    (many webservers)
    and/or
    (many drupal installations)
    - -

    Comments

    Popular posts from this blog

    Configure drupal_http_request() on the fly

    The drupal_http_request() function supports connections using a proxy. You can configure a global proxy to use for all drupal_http_request() callbacks from the settings.php file of your website/installation by filling the following lines with the proper information:For those of you preferring a UI, then HTTP proxy module is for you.But what if you only want to use a proxy in some cases; like a custom module? In that case you will need the following function(modify accordingly):Now all you have to do is Call <?php _MYMODULE_change_proxy(); ?>.Do your drupal_http_request() calls.Call <?php _MYMODULE_change_proxy(TRUE); ?> to reset your previous settings.

    Drupal: Allow registrations through Invite or Referral modules only

    The Invite module provides invitations from existing users to their contacts. The Referral module, in contrary, creates a special URL for each existing user, which can be found in each user's profile, and allows new user registration. Even though, these two modules seem to provide the same functionality, they don't (and they shouldn't). Invite module, provides a mechanism for a site administrator to limit new registrations to "Invitations only". Referral module doesn't provide any of this functionality. Some users have requested the Invite module and Referral module to join in one module. Until now, there isn't anything to that direction. Wouldn't it be great though if there was a solution to limit drupal registration to referral or invitation only? Copy the functions below to a refinvite.module file in your sites→all→modules→refinvite folder and enable the module. Then go to http://<your-address-here>/admin/user/settings and enable the new …

    Send mass email to certain users using VBO

    Views Bulk Operations uses the built-in actions to act upon nodes, users, entities etc. Among these actions is our ability to send emails to users. If you try to use this action though you will encounter a small but serious problem. You are asked for an email address to send your message. You might say "but I have selected the users I want this message to reach. Why should I input an address again?". Don't get overwhelmed. What this field expects is not an address but a token. Specially this token [user-email]. If the website is intended for you, then you might say that's not such a problem to write this token down again and again. But if the manager of the website is bound to be the client or if you just want to spend less time writing things down, you might prefer to use a custom hook_form_alter() callback to set a default value. It could be done in both theme and module environment so suit yourself. Just add the following in your module or theme.