Drupal Multisite

It seemed strange to me that this topic is practically not covered on the hub, and I will try to fix this situation a little.

I am not a supporter of Anglicism, but in our language there is not even a similar term. In short, multisiting can be defined as the ability to use engine files for different sites. I will not understand the etymology of this word, but I dare to suggest that its appearance was associated with Drupal. One of the most common examples of multisiting can be the use of a common user database on several sites. In Drupal, multisiting is implemented attractively, in terms of simplicity and convenience, which I decided to write about.

Instead of joining

In my opinion, Drupal is a plasticine from which, if desired, you can dazzle very nice little things. Although my experience with Drupal is not so great, but so far I have not happened to meet a problem that could not be solved with its help. I must admit that if the developer’s knowledge / motivation / experience level is small, then this plasticine will most likely produce a handful of known non-drowning mass, but this is not about that at all.

How it's done?

It should be noted the logical literacy of the construction of the Drupal folder structure. The kernel is separate from the native code, all code is separate from the markup. Multisiting is provided by Drupal out of the box, for which there is a sites folder in the root directory. This folder should contain the settings files for sites that are in conjunction with the main site. People who have installed Drupal at least once know that Drupal requires the creation of the settings.php file in the folder.

sites/default

In this case, the name of the folder 'default' determines its belonging to the “main” site.
In the case when you need to organize multisiting, folders with domain names are created next to 'default' and the settings.php files from sites / all / default / default.settings.php are copied there

sites/first.example.ru/settings.php
sites/second.example.ru/settings.php
.
.
.
sites/n.example.ru/settings.php

which indicate specific settings for this site. Themes and modules that need to be made available only for the specified site are placed in the appropriate folders. Themes and modules placed in the folder will be available to all sites in a multisite bundle. Thus, you can significantly reduce the time to update them. Important! Document root for all sites in the bundle should have one - the root directory with the Drupal installed (where index.php lies). A symlink option to this folder is also possible.

sites/first.example.ru/themes/
sites/first.example.ru/modules/



sites/all

How to name folders?

While searching for settings.php files, Drupal “truncates” the names of subdomains from left to right, and the names of subfolders from right to left. From the example, it should become clear what is meant by this.

Let's say the site we have to be installed in

www.example.ru/mysite/test

Drupal will look for the settings.php file in the following folders in the specified sequence: The first file found will be used, the rest will be ignored. As you can see from the example, for the example.ru site to work, it’s enough to place settings.php in and you do not need to duplicate it in because and on appeal through example.ru, and on appeal www.example.ru Drupal will find the same file.

1. sites/www.example.ru.mysite.test
2. sites/example.ru.mysite.test
3. sites/ru.mysite.test

4. sites/www.example.ru.mysite
5. sites/example.ru.mysite
6. sites/ru.mysite

7. sites/www.example.ru
8. sites/example.ru
9. sites/ru

10. sites/default



sites/example.ru/settings.php



sites/www.example.ru/settings.php



In case you need to bind a site installed on a non-standard port, the port is indicated as an additional subdomain. So, for the site, the

www.example.ru:8080/mysite/test/

folder with the settings.php file should be

sites/8080.www.example.ru.mysite.test

On my own I’ll add that I would not recommend linking the sites installed in the subfolder, because their correct functioning is not guaranteed (as stated in the documentation). There are, of course, recommendations for fixing possible errors, such as creating a symlink document root for www.example.ru.mysite on document root for www.example.ru :

(из document root для www.example.ru)
ln -s . mysite

but this is not a panacea and you need to choose this method only if absolutely necessary.

What to change in settings.php?

1. If we want to use completely independent sites

then in settings.php in $ db_url we specify a separate database. The user may also be different. The presence or absence of a prefix here does not make any difference, but, again, I add from myself, assigning prefixes to the site database is, although not a big one, but a security tribute and should not be neglected.

2. If we want to use sites with a common database or with shared tables

a. if sites will use the same database

then you need to use different prefixes for unique tables and the same for general tables. For example, common_ is conceived as a prefix for shared user and profile tables, default_ for own database tables of the main site, and first_ for own database tables of the site first.example.ru.

In sites / first.ru / settings.php we write: In sites / default / settings.php Thus, the site first.example.ru will use a common database of users and their profiles with the site example.ru. But do not get involved in this way, because on average, with each new site in conjunction, the number of tables will increase by 60-70. It is easy to calculate what will happen to the database at ten sites. Add to this the dependence of all sites on the correct operation of one database.

// $db_prefix = '';

$db_prefix = array(
"default" => "first_",
"users" => "common_",
"sessions" => "common_",
"authmap" => "common_",
"profile_fields" => "common_",
"profile_values" => "common_",
);




// $db_prefix = '';

$db_prefix = array(
"default" => "default_",
"users" => "common_",
"sessions" => "common_",
"authmap" => "common_",
"profile_fields" => "common_",
"profile_values" => "common_",
);


b. if sites will use different databases and some common tables.

Let's say we need to use:

• general views (created by the views module)
• common database of users and their profiles for example.ru and fisrt.example.ru sites

and suppose that:

• DB name for example.ru - example
• the table prefix for example.ru is example_,
• DB name for first_example.ru - first
• the table table prefix for fisrt.example.ru is first_.

In sites / first.ru / settings.php we write: In sites / default / settings.php In this way, for first.example.ru, data about views and users will be taken from the example database, and all the rest from the example.ru database Important ! The dot here is interpreted by the Drupal as the end of the database name, so you should not create a prefix with a dot.

// $db_prefix = '';

$db_prefix = array(
"default" => "first_",
"users" => "example.example_",
"sessions" => "example.example_",
"authmap" => "example.example_",
"profile_fields" => "example.example_",
"profile_values" => "example.example_",
"views_display" => "example.example_",
"views_view" => "example.example_",

);



$db_prefix = 'example_';

Conclusion

Drupal multisite is quite simple to configure and works stably. I didn’t have to deal with problems, despite the fact that in order to accomplish this task, I needed to combine the views_display, views_view, blocks and blocks_roles tables, while Vlad Savitsky classified blocks * as tables that cannot be joined, and views_ * as tables, combine which you need with great care.
Max Kirilenko , on the other hand, believes that “Multisitenig on common tables is an undocumented feature of Drupal, it has more problems than advantages.” But his article is about Drupal 5, and maybe that’s the reason.
Waiting for comments on this.

Two useful modules on the topic:

Multisite search - allows you to index the contents of sites in a bunch and search on them
Multisite login - allows you to save authorization for all sites in a bunch even on different

UPD domains : pvasili advises you to be careful when updating modules in the / sites / all folder (be sure to run update.php on all domains using this folder).
UPD: First, Drupal will look for a module in sites / example.ru / modules, and after that in / sites / all / modules
UPD: To update via drush andyceo, he wrote an UPD script
: shuba described a useful innovation for Drupal 7