7

I am thinking about implementation of some sites with multi-site and idea of solution (one code-base) is perfect for me even if shared table is not supported any more (my question about shared table is here also i'm aware of domain module too).

After some search, I found this topic about plan to deprecate multi site in 8.x and removal in 9.x.

My questions are:

  • How serious is deprecation in 8.x and removal plan of multi-site in drupal 9? the topic is in category of plan for two years.

  • Even if removal happens in 9.x, we have to expect some migration path to removal of 9.x or not? In my idea this migration didn’t happen for shared tables.

  • Proposed solution for removal of multisite in mentioned topic is

The modern approach to multi-site is: git — Same code, different sites. Under your control. And well-maintainable.

I can’t understand it. How does it works?

9

You have a few questions there, so I'll hit them individually:

How serious is deprecation in 8.x and removal plan of multi-site in drupal 9? the topic is in category of plan for two years.

It's hard to say. Controversial topics like that can go in circles for years in the open source community. As you can see, that topic started over three years ago, and still has not reached a conclusion, and may well never reach one.

Even if removal happens in 9.x, we have to expect some migration path to removal of 9.x or not? In my idea this migration didn’t happen for shared tables.

It will be fine even if you are sharing tables, as you can just migrate each multisite to a new individual site. You may have to do a special database dump and import to get the shared tables into your new system. I did this once when migrating from D6 to D7 for my company site - I was using multi site, and in the upgrade, I just created two sites out of the one.

I can’t understand it. How does it works?

Git keeps all your code in a repository, which you can clone as necessary. So any time you need to spin up another site, you just clone the code, and you have a new Drupal instance. As you update sites over time, you can merge the code changes from one repository to another.

In my own company system, we have a central repository for each project. Any time someone new works on the project, they clone the code from the central repository, and they have an exact copy of the site. We then clone the repository to the webroot, so that it is available over the web. When people make changes to the code, they push the changes to that central repository, and then anyone can pull them at any time to their own repository, and/or the repository stored in the webroot of the public site.

  • thank you @Jaypan. so idea behind git is same code and not one code. so i think it hasn't benefits like one time update, shared module.....it seems in my case git only increase complexity. – user780 Jan 21 '17 at 7:36
  • also about your d6 to d7 migration: shared table is ok in d7. didn't migration work for multi-site so you decided to go with 2 different sites? also file path in main domain is like sites/default/files/ and for subdomain in multi-site is like sites/subdomain/files/. after separation of two sites you hadn't problem with file load? – user780 Jan 21 '17 at 7:37
  • 1
    Once you learn GIT, it's excellent. I can update 10 sites three minutes. It's much better than multisite. I switched from multi-site to two sites when I went from D6 to D7, because D7 caused too many troubles. – Jaypan Jan 21 '17 at 8:02
2

I've used Aegir for multi site management, great tool!

If you have ever used Amazon Web Services, it's similar like that but for Drupal. With a click of a button you can launch specific site builds.

Here is a quick overview tutorial on it

All it takes to update your site is a click of a button (Migrate button, disabled by default, read docs on how to enable it).

Aegir behind the scenes uses Drush to accomplish the bulk of the work, such as drush make files for installation, drush dl to download modules, etc...

0

The Git solution solves the problem of cloning an existing site. Each clone will contain a complete copy of the Drupal environment, which has an overhead of 53 MB as of Drupal 8.1.1 (87 MB actual disk space used in my file system).

Given the cost per MB of today's disk and SS drives, this overhead is not a serious problem for most of us. However, during development we may have many experimental and pedagogical sites saved in our file systems. Drupal's multisite feature, properly configured, can save a lot of file space in this case. This is a strong argument against removal of the feature.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.