Geekly Articles each Day
📜 ⬆️ ⬇️

Multisiting in Drupal


It seemed to me strange that this topic was practically not covered in Habré and I will try to correct this situation a little.

I am not a proponent 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 may 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 intro


In my opinion, Drupal is plasticine, from which, if desired, you can make very nice little things. Although my experience with Drupal is not so great, but so far I haven’t happened to meet a task that I couldn’t have solved with its help. I have to admit that if the level of knowledge / motivation / experience of the developer is small, then this clay will most likely have a handful of well-known non-sinking mass, but this is not the case.
')

How it's done?


It is necessary to note the logical literacy of the construction of the Drupal folder structure. The kernel is separated from its own code, the entire code is separated from the markup. Multisiting is provided by drupal "out of the box", for which there is a folder called sites in the root directory. This folder should contain the settings files of sites that are in conjunction with the main site. People who have installed Drupal at least once know that Drupal requires creating settings.php file in the folder

sites/default

In this case, the name of the folder 'default' defines 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 are copied from sites / all / default / default.settings.php

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

which specify the 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.

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

Themes and modules located in the folder

sites/all

will be available to all sites in the multisiting bundle. Thus, you can significantly reduce the time to update them.

Important! Document root for all sites in the bundle should be one - the root directory with the drupal installed (where index.php is located). A variant of the symlink to this folder is also possible.

How to name folders?


In the process of searching for settings.php files, the drupal “cuts off” the names of subdomains from left to right, and the names of subfolders from right to left. From the example it should be clear what is meant by this.

Suppose we have a site set to

www.example.ru/mysite/test

Drupal will look for the settings.php file in the following folders in the specified sequence:

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

The first file found will be used, the rest are ignored. From the example it is clear that for the work of the site example.ru it is enough to place the settings.php in

sites/example.ru/settings.php

and don't need to duplicate it in

sites/www.example.ru/settings.php

because and on the request through example.ru, and on the request of www.example.ru Drupal will find the same file.

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

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

folder with settings.php file should be

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

From myself I would add that I would not advise linking sites that are installed in a subfolder, since their correct functioning is not guaranteed (as stated in the documentation). There are, of course, recommendations for correcting possible errors, such as creating the document root symlink for www.example.ru.mysite to 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 when 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 the prefix here does not matter, but, again, I add on my own, assigning prefixes to the site database is, although not great, but a tribute to security and should not be neglected.

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

a. if sites will use the same database

you need to use different prefixes for unique tables and the same for general ones. For example, common_ is designed as a prefix for common user tables and profiles, default_ for own tables of the main site's database, and first_ for own tables of the site's first.example.ru database.

In sites / first.ru / settings.php we write:

// $db_prefix = '';

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


In sites / default / settings.php

// $db_prefix = '';

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

Thus, the site first.example.ru will use a common c base of example.ru base of users and their profiles. But do not get involved in this way, because on average, with each new site in the bundle, the number of tables will increase by 60-70. It is easy to calculate what will happen to the database already at ten sites. Add to this the dependence of all sites on the correct operation of a single database.

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

Suppose we need to use:

and suppose that:

In sites / first.ru / settings.php we write:

// $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_",

);

In sites / default / settings.php

$db_prefix = 'example_';

Thus, 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 point here is interpreted by the drupal as the end of the database name, so you should not create a prefix with a dot.

Conclusion


Drupal Multisiting is fairly easy to configure and works stably. I did not have to deal with problems, despite the fact that in order to accomplish the task I needed to combine the views_display, views_view, blocks, and blocks_roles tables, while Vlad Savitsky classified blocks * as tables, which cannot be joined, and views_ * as tables, which need to be combined with great care.
Max Kirilenko also believes that “Multisitebook on the general tables is Drupal's undocumented opportunity, it has more problems than advantages”. But his article refers to Drupal 5, and perhaps this is the reason.
Waiting for comments on this.

Two useful modules on this topic:

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

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

Source: https://habr.com/ru/post/133086/

More articles:


All Articles