Multisite is a valued feature that will not be deprecated.

+1. Multisite is a historical oddity at this point and I'd never tell anyone to use it.

+1 wholeheartedly agree, there are lots of better solutions to the problem, and we made everyone deal with /sites/ directories for years.

-1. Multisite has been a workhorse for a ton of Drupal sites and is well established in our code.

I think the core reason to at least postpone this issue would be IMO be a new beta blocker and we need to not do that.

I also disagree with some of the arguments. Running down the motivations in the summary:
1) Also created over a decade ago: databases, nodes, the fundamentals of entities... FormAPI is also pushing a decade. Age does not equate to obsolescence.
2) This may be a weakness. Its something we fight continuously everywhere so this alone can't drive our decision.
3) This is dramatic and exaggerated. There is a core functionality of "multisite" where this is not the case. What you seem to be arguing is that shared tables are pretty broken and I agree.
4) Sometimes. @see #3. Removing this will require additional advanced setups/deployment strategies and possibly core hacks to recreate the same feature so the sword cuts both ways.
5) This is not the same thing. I don't see how we can argue having some functionality now, that is also removed by the issue, is an argument for removing the feature.
6) I was ok with this change because we where not removing multisite. Its not fair to now use it as a argument for removing it unless we can go back and start this argument to block that issue.
7) opinion? @see #1

Yeah I'm not seeing the argument for removing multi-site in general. Shared tables I agree is completely broken - if you share tables, nothing then tells you whether specific cache bins should or should not be shared. If you remove that from the issue summary, there's not much of an argument.

1. It still makes sense to have only one copy of drupal core in your server, without filling APC.
   ditto for modules.
2. You can also update those stuff only *once*.

Unless someone proves that 1) is obsolete, this is wont fix

-1 to remove!

All 7 arguments just points about complexity but it works!

Shared tables just needs some love but they works for 6.x and 7.x - I've used this a few times but it's ok to remove.

-0.5

1. I would not break something what is working good
2. That's fixable
3. Sharable tables is not a good idea, we can get rid and ensure multiple sites are using different tables. I've never seen any errors though.
4. Custom settings could be easily solved by some kind of inheritance or inclusion.
5. 6. This should be in conjunction, and/or documented.
7. why? It really saves disk space and helps to manage 200+ sites. Otherwise you need to use Aegir or an alternative.

Some sales use multi-siting to sell Drupal. Some hosting companies provide SAAS services based on multi-siting. A ton of sites use multi-siting.
Let's remove this issue completely ;)

I see the problem now.
People believe that sharing the same module files (and updating them at the same time) between 200 sites is a neat idea, and not something to be feared and avoided.

those 200 sites could be dev sites and they are using the multisite feature to cut down resources and costs.

I have never used the 200 mega-site feature or a the shared tables feature, but multi-sites are very helpful when managing a small group of sites with identical functionality. Benefits of using a multi-site for this kind of use case that I can see:

1. Guaranteed replica production environments. You can be assured that production is always the same across your live multi-sites.
2. Single deployment setup, no need to setup deployments to multiple locations.
3. Easier local development, test changes to the codebase across different databases with a single refresh vs make change, switch database or sync files.

I've run a D6 multi-site for about 5 years, with one code base supporting about 50 websites/domains. My main motivation, is that if there is an update, I upload just one set of files, and not 50 sets of files, duplicating and increasing my workload fifty-fold. I can enable modules for each site separately, have a unique database per site, and unique /files directory per site.

It's not perfect, and there are some minor issues, that include:

• I still need to take 50 sites offline, and run update.php on each one. The workaround is to use the Drupal Remote Dashboard module, which lets me do this relatively easily. I've already suggested that there should be a "Multisite global module update ability".
• Some file paths are hard-wired to the /sites/example.com/files subdirectory, which can make moving sites difficult. See "multisite image/file paths"
• There is a cross-site vulnerability, where one of my multisites can access images and files on another multisite, eg. a site www.multisite.com/sites/multisite/files/filename can also access www.multisite2.com/sites/multisite/files/filename

The multisite feature could be documented better, but it works.

-1

This has been discussed at length and while you may have great motivations for never using multisite, others have been and continue to use it for the advantages it does provide. No one is forcing anyone to use multisite, so why are we talking now about forcing people to drop it? And at this stage of 8.x development? I'm in favour of simply not using it if you don't like it, but not in favour of dropping it completely.

-1

Shared tables are bad, single codebase still has good advantages.

• Shared copy of code in APC for a setup with many sites on same host.
• ease of deployment of code, for network of similar sites
• ...

Multisite feature can be better documented.

-1

...there's a 99.9% guarantee that your sites will blow up

D8 only enables the multi-site functionality, if /sites/sites.php exists, so as to skip it for the 99% use-case

Not sure where these "statistics" are coming from but 6 years of of working with D6 and D7 multisites without significant issues say otherwise for MY use-case. What do you say to those companies whose entire development process, management tools and hosting infrastructure is built on multisite?

Not sure if this is still a valid issue now that we are in beta.
I am going to comment nevertheless, because it would affect other things I am working on.

-----------

A negotiable -1 from me at this point.

Use case for multisite

I have used multisite myself, and I think there are valid use cases. As I see it, the necessary criteria are:

• The sites have a lot in common.
• Future development should apply to all sites likewise.
• The sites are maintained by the same team of developers / site builders.
• Testing / validation of changes can be done on all sites at once.

If all these criteria are met, then the shared codebase becomes an advantage. If not, it becomes a problem.

Seeing that a lot of people are using multisite successfully, I think we should be really cautious about the idea of removing it.

Complexity

I do agree that multisite makes some things more complex:

• Some bootstrap logic has to run before a container is available, because we need to figure out which site directory we are in, before we can do anything with the container or with modules. A lot of this currently in DrupalKernel, but a lot is still in procedural code.
  Dropping multisite would make it easier, but there is still some pre-container logic required for the installer and maybe other things.
  It is tricky, but I think we can cleanly manage it with #2354475: [meta] Refactor the installer, (multi)site management, and pre-container bootstrap
• Site-specific composer.json based on module dependencies bites with core composer.json (this is currently not implemented, but will be at some point, I hope. Or use composer_manager)
• Web tests: I am not sure if they actually suffer or benefit from multisite. Isn't it nice being able to set up a temporary site directory with its own settings.php for testing?

For me the composer issue is really the biggest concern. But maybe we can find a way.

Alternatives?

There are a number of ways to achieve multisite-like features without multisite:

• Separate code bases, synced with git.
• Parts of the codebase shared with symlinks (not sure what APC makes of that).

We could also keep multisite, but tame it a bit:

• Keep multisite, but let each site directory have its own index.php, and let Apache handle the switching logic.
• Keep multisite, but require all module composer dependencies to be the same across sites, so we don't need to maintain separate vendor directories that are different from core/vendor.
  (as said, this currently only happens in contrib composer_manager, but there is definitely a use case for having this in core)
  See also https://blog.erdfisch.de/2014/08/composer-based-workflow-drupal-8, and my comment there.

While some of these sound nice, some discussion would be required before we do any of this.
I also suspect that the options are limited, now that we are in beta phase.

This discussion is old but I have not found any new writing about Multi site and composer.
Is it still problems with composer and multi sites?
Have a multi site and is trying to download requirements with composer command but fails.
Getting this error:
The requested package league/csv ^7.1 is satisfiable by league/csv[7.1.0, 7.1.1, 7.1.2, 7.2.0] but these conflict with your requirements or minimum-stability.

Is multi sites and the composer logic in conflict?

@chrotto I'd probably open a new issue with more details about what you're doing and how its failure.

As far as this issue, I'm going to be bold and push it to 9 because to do finish this process in 8 we'd definitely break out release rules around API's.

I'm with you on this. One, removing multi-site from 8.X.Y would be the mother of all BC breaks. I don't even see how we could provide an upgrade path. Two, I think we really need a better understanding on use cases for multisite so we can implement it properly. This was originally a way for people on shared hosting and other constrained hosting arrangements to have multiple sites to run multiple domains. I have also see it used in academia to provide consistent environments across lots (and I mean LOTS) of sites. There are better ways to handle both, but we are seeing multisite still being used. So, I think we need to work backwards from real-world use cases and developer a proper solution.

If we're going to consider removing it in 9.x, it should be deprecated in 8.x first. So moving back but retitling and shifting to plan.

Agree very much with #22 overall. We need real life cases where people are using multisite in 7.x (or ideally 8.x), then document what the better alternatives to those are.

Thanks, that's a better way of setting the metadata on the issue. Took a stab at bringing the summary up to date.

-1

I have a case of near 100 sites that really need only to share the code without tables and that are on the same server.
Multisite feature (especially sharing code without duplication) was a strong argument to choose Drupal for this project !
it's really not needed and not optimal to duplicate that code 100 times.

@izus: What do these sites have in common, and what makes them different?

When starting my new project with Drupal 8, one of the benefits was an easy way to set up multi site.
I must say I am very surprised if it shows up that one important part, composer, not is functioning on the multi site concept.
My multi site project is to deliver the same service to different organizations, there only settings differ between them. It seams not the most effective way to have the exact same code loaded for every site. The organisation shall have there own administration and settings possibility and for security reason I must have them in different databases.

@donquixote : they all use drupal core and share all the modules and themes, configuration is different and they may have different enabled modules but can need at any moment the other non yet enabled modules.
(actually these are associations that have more or less the same global needs but they need to be able to configure stuff differently and frequently in the admin interface)

Multisite works well for me with 50 sites sharing a common code base, and different databases.

The only improvements I would make is being able to access, install and update modules for all sites, from a single master control panel, similar to Drupal Remote Dashboard. This lets me put all sites into maintenance mode, update a core module, run Update, and make the sites live again.

I have worked on a few projects that use multisite.

I think the valid use case is if all sites are technically built and maintained by the same team, but to users and visitors, and possibly content authors, they should appear as separate sites.

One time I had to work on one instance of a multisite, without really understanding what the other instances were doing. This is generally something to be avoided, because you don't know what you might break.

I would say multisite has some issues with deployment. You either work directly on production (say what you want, this is what happens out there), or you have to deploy settings on all sites simultaneously.

AEGIR system mitigates the issue described in #31. You create a new platform and migrate the multi sites 1 by one 1. If anything fails AEGIR does backups and allows you a restore option, so it's not all or nothing approach.

-1

Many organizations maintain their in-house Drupal distributions with a set of custom modules and themes that are then installed and configured on per-site basis.

Opcode caching becomes a problem when multi-site is not used leading to the exact same code being duplicated hundreds of times.

-1

We are using Aegir to host 100 sites on 7 different servers. All Drupal 7 sites shares the same Drupal core and sites/all/modules folder. And any site specific module (patched or custom) is in the sites/[domain)/modules folder. One Git report for the platform, And each site (sites/[domain]) has a git repro.

For use it takes 1 hours to upgrade a module for all sites. This includes, downloading the module, test it on dev environment and push it out to servers using Ansible. And of that 60 minutes, 15 minutes is manually work. Rest of 45 minutes is just Aegir migrating site from one code base/platform (with old module) to new code case / platform, (here I go and take the Swedish fika (coffee)). And if problems comes it will rollback migrate and it can be handled manually. Individual site is in maintenance mode just a few seconds/minutes. And if more modules are update the same only the download and testing part is scaling. And scaling up sites for use is no problem, as long as we do not need a additional server because of a customer requirements.

On one of our server we have 26 different site sharing Drupal 7 platform and 6 different sites sharing one Drupal 8 platform. Our Opcache in PHP is 128 MB and is filled to 96%. The machine is a VPS with 4 GB and 4 CPU, has a Mysql with 2 GB innodb cache.

Doing some math. According to our OP cache 87 MB is needed for Drupal 7 with all of its sites. 38 MB is needed for Drupal 8 but there we are not using so many modules. So lets say if every every site would required 40 MB memory for OPcache. It will required us to have 1280 MB memory just for Opcache, and this memory will increase with every site and can not be shared between sites. Like PHP/Apache and Mysql can.

So for us a removing of multisite will mean more work for each site and more hardware.

-1

I strongly reject the premise. If you are blowing up your sites 99.9 percent of the time, you're doing something wrong. I've used multisites for many years for low-yield sites as a way to make maintenance far more manageable. Multisite functionality is a key attractive feature for using Drupal.

That said, whether you use multisites or not depends heavily on whether your server(s) can adequately support the aggregated weight of the sites. It's a valuable tool, but indeed it is the wrong tool in certain circumstances.

Ever heard of or used the multi site management system called Aegir???

One thing that needs to be addressed in the new 'off the island' world of drupal and composer is that modules are no longer something you simply download and place into a folder. You composer require a module in order to download it to a single folder, and its dependencies get placed in /vendor. As more and more modules utilize the approach of having a dependency on a composer package, this is going to move towards becoming a defacto requirement of site building.

In composer's data model you are running one application off of one codebase, and in the multisite model of drupal you are running multiple applications off the same codebase. So we have a collision here about to handle this sort of build. Are there multiple autoloaders for a multisite? Multiple vendor directories? How do we tell composer where modules are destined to be stored on the filesystem? Drush knew how to do this based only on the directory that it happened to be executed in.. Do we need to introduce composer scripts that allow for that kind of introspection too?

@Mixologic
I would suggest to think of multisite as one application and one codebase which powers multiple websites.
For this we would need to rethink what we allow to be site-specific and what has to be shared.

Shared:
- composer vendor directory
- composer autoload setup
- possibly all php code?

Site-specific:
- database connection settings
- file uploads
- the service container?

If the main use case for multisite is to power sites that actually do have a lot in common, then this would work.
If, instead, the purpose is to power a random collection of sites where the only shared thing is that they run Drupal, then.. it will be tricky.

Btw shared code base is a main profit - less memory used for opcache
Also it maybe helpful when domain module is too hard to configure or maintain

-1, let's keep it
Multisite is widely used. We use it even on Acquia. It is a nice feature even for development purposes, when we can set local dev equal to prod with different dns

-1 from me. While I'm now using a composer/container workflow that does not involve a shared base install, at least one client may still wish to have multisite as an option.

Multisite with one DB per site is useful and not a difficult concept. Are there really problems with that?

Shared/prefixed tables is the "feature" that should be deprecated. Domain module does a better job?

I think inline with the latest comments it would be sensible to deprecate (8.x)/remove (9.x) the ability to have per-site modules and themes. That doesn't work with Composer as #38 anyway explains and in the world we live in that means it doesn't work (TM). And even without Composer it complicates the update process - which is already complicated enough in its own right - by about a billion. And of course you can still have a different set of modules/themes installed per-site, just the availability of modules/themes would be "global".

If we do that we would still have per-site:

• database connection
• service container
• user-uploaded files
• settings
• configuration overrides
• anything else you can do in settings.php/services.yml

Which would be fine by me or we could also discuss to deprecate/remove multisite completely. But I think it would be great to get consensus/approval on the module/theme discovery issue first, as that is the thing IMO that turns the headache caused by normal multisite into a fully-fledged chronic migrane.

I agree with #43. That emphasizes the "shared code, different configuration" approach.

#42,

Multisite with one DB per site is useful and not a difficult concept. Are there really problems with that?

There are compromises in the kernel to support multisite, along with complications in the module/theme discovery process. It's a technical debt thing.

I think the approach outline in #43 really is the best option. However, with some of the workflows I have heard about multisite in academia, the theme/module thing per-site is heavily used.

For example, the web group develops an installation profile for the base-multisite install. People/groups/departments can then add their own theme and get approval for additional modules (as well as their own custom modules), which others don't see.

I think we still need to develop some better use-cases of exactly how and why multi-site is used, so we can weigh the pros and cons of any solution we move towards.

I think we still need to develop some better use-cases of exactly how and why multi-site is used, so we can weigh the pros and cons of any solution we move towards.

+++++

just the availability of modules/themes would be "global".

I wonder if there are any real world use cases of needing *different* versions of the same module in a multisite? Perhaps a module is upgraded to the newest version in one of the sites to verify the upgrade path and test, without forcing an upgrade to all of the sites simultaneously?

#46,

I wonder if there are any real world use cases of needing *different* versions of the same module in a multisite? Perhaps a module is upgraded to the newest version in one of the sites to verify the upgrade path and test, without forcing an upgrade to all of the sites simultaneously?

This is where the use case comes in. In the dark days where I was still using svn, I used multisite to have dev/stage/prod on the same server. I typically didn't care about core updates breaking things, but contrib sometimes would (at the time). I don't do this anymore, as there are better ways to handle dev/stage/prod workflows (both code and servers). So, it people are still doing this, then the solution is education/documentation.

Other scenarios to consider:

- A specific custom module meant for only one site is considered "dirty and hacky", and we want to be absolutely sure it is not available on any of the other sites.
- separate theme per site, with a lot of sites, now all spamming the system table.

Name clashes can be prevented with a per-site prefix. But Drupal would still need to discover all of the different themes / modules.
Maybe this is ok if the result of this scan is cached in a shared cache layer?

if there's a way to run 100s of sites off 1 server with 1 code base to update (different databases pointed to) that'd be the primary concern with talk of dropping multi-site. If it was purely dropped, education would have to find ways of hacking it back in since we can't all run cloud infrastructure in large teams to be able to have dedicated ops people in the name of "doing it the right way". As one managing 100s of sites off a handful of code bases across a handful of servers, multisite is a large part of why we use drupal.

Can you screw it up, yes, much like any other part of the stack, but criticism as antiquated alone is a weak reason. I like the notion of possibly removing the locally loaded module directory per site, though having the ability to define other locations for sites to bootstrap their modules from would be ideal.

Our organization maintains several large multisites with the following use cases:

• Each codebase has one or more installation profiles. Currently we maintain two installation profiles:
  • One which is used for allowing departments to have a web presence who have no/limited budget. These sites have common shared features: news, events, etc and a handful of themes that the department can use. No custom modules or themes on a per-site basis.
  • The second installation profile is for departments who require a more custom site build and we run this in a cost recovery model. In this case, we utilize a shared set of installed configuration and modules, and our team then does custom development on top of the base platform. Each site generally ends up having its own theme and custom features.
• We see benefit in having the ability to have different versions of the same module available on the code base per installation profile. This allows us to upgrade all of the "standard" sites independently of our custom service. I'm not sure how we could do this in the composer workflow, since it seems like those separate dependencies all would get negotiated down to one module in the vendor directory.

-1

Multi site remains as a useful tool to run Drupal in higher ed

Remove it in D8/9 and we'll probably stick with D7 until a better non-Drupal solution emerges.

E

- 1 I'm going to add to the higher ed use cases. We don't do traditional core multisite. We use https://www.drupal.org/project/dslm to manage the symlinks similar to what was mentioned in #39. Even with ~1000 sites, APC sees the symlinked files as only existing once and thus they are only cached once. While we may be moving to a container architecture when the symlinks would be replaced by caching at a higher, we often hire people BECAUSE they have experience with traditional Drupal multisite. Multisite is also very popular with WP. The idea that the skills we need to run Drupal as a service at scale could only be learned by running Drupal as a service would be troubling.

-1

-1. Used multisite to run a SaaS. Fit use case perfectly.

EDIT: In my use case I would not want different modules per site. But a way to ensure multiple site definitions and databases for a single code base.

+1

The multisite feature is important, but the current form in the core is unnecessary.
Especially after the adoption of Git and Composer, we can have several sites with a clean core and share the dependencies.

after the adoption of Git and Composer, we can have several sites with a clean core and share the dependencies

@jvsouto you can, but not everyone can. Supporting a feature the way something has always been done back on the island vs. embracing the new things we found off the island is a recurring theme in many Drupal threads these days. I just want to reiterate that WordPress supports multisite "out of the box" and removing support for this in Drupal impacts a pipeline for developers familiar with this even further. When universities can't hire developers for a technology, they are much more likely to move to a technology that it is easier to hire. The last 2 Drupal developers we've hired had done traditional Drupal multisite at some level. Without that, we'd have to resort to poaching more of the @bneil's staff. When he runs our of poachable staff, we'd probably be forced to switch to using WordPress to offer CMS as a service.

Just going wild here:
Maybe Composer (or PHP itself) could introduce a feature where multiple PHP projects would use a shared pool of php vendor files.
This would make Drupal multisite obsolete, if the only purpose is to limit memory usage.
Of course such a pool would need to be able to have multiple versions of a vendor library simultaneously. Or possibly work with file hashes.

I am trying to get a BOF together to discuss the use cases at Drupalcamp NJ. If we can't get the formal BOF room, we can discuss in sprint room (there will be people there who know impacts of multisite on core, and I will be there F-M) or figure out a place to talk. I'll scribe and post notes afterwards.

Matt, Make sure I don't miss it.

Ambivalent. I never use multisite in production, but in testing, I sometimes use `default` for the clone of the live site's database, and a multisite for a database created from test fixtures. It's nice to be able to set up test fixtures in a way that does not touch the default database. I suppose if this feature went away, tests could find some other way to use an alternate database.

If multisite is maintained, maybe we could at least remove support for shared tables.

Please no.

You can argue about how accurate the data from http://tri.be/blog/wpcampus-survey-wordpress-trends-in-education/ is, but it's a large survey where the results where shared.

To answer these questions, the folks behind WPCampus conducted a comprehensive survey of WordPress users in the education sector. 486 people responded, and we discovered key WordPress trends across educational institutions large and small.

Results https://docs.google.com/spreadsheets/d/109Rk_AbGVBGurUaKc5icnVO5i24NMtc_...

Some select stats from the "What were the core factors in choosing WordPress" question...

Open source 68.6%
Ease of use 81.5%
Extensibility and flexibility 70.6%
Development speed/cost 55.2%
Security 18.2%
The WordPress community has a large talent pool. 37.7%
Its commitment to backwards compatibility 16.5%
WordPress Multisite 39.7%
SEO 19.5%
Media management 11.2%
REST API 4.4%

While higher education is just one market where Drupal competes with WordPress, universities are also in a relatively unique position to run Drupal as a service where multisite is a very important feature. While insane, this survey shows that multisite is more important that SEO, Media, and REST support. It's even more important to this group than security?!?

I can only speculate on why this feature rates so high with WordPress users in higher ed, but my guess is the people filling out this survey remember what it was like running hundreds of custom sites in their own repos.

While I understand that there are many ways to do many Drupals, removing multisite from something that is supported by Drupal core is going to play poorly in higher ed.

-1

This was a reason I chose to start working with Drupal (at D7 release). Unless this has too much technical debt attached to it going forward I can't see any valid reason for removing this.

1. Drupal's built-in "multi-site" feature was invented a decade ago.
2. It is hardly documented.

I completed a multi-site build after only a couple of Drupal projects completed and Drupal was the first CMS I'd ever used. On the Drupal learning curve of things it's not that difficult to understand and deploy compared to say Rules or complicated Views. The documentation is as good as anything else, really.

I doubt Drupal.org > Documentation is a first source of documentation for most users.

1. IF and after you managed to set it up, there's a 99.9% guarantee that your sites will blow up with unrecoverable errors and data loss — especially when running module updates (due to potentially shared database tables).

I don't understand why this discussion is so focused on shared databases. I thought this was a well-known 'No No', the documentation and installation prefixing option is there but you learn early to never use it. What's the use case or benefit? This may have made sense way back in the day when hosting packages limited the number of databases.

I never had any issues with my multi-site builds.

Again this is bit of a 'how Drupal is documented and some times used' vs. how you actually get things done with Drupal and learnt to use it. Anyone who is that inexperienced with Drupal to misuse or use shared databases is going to break their site a thousand times during the build/development process. One more 500 error won't matter.

1. It requires custom settings as well as highly advanced customizations and custom code changes for Drupal core to work out in practice — built-in features should not require you to hack core.

Hack core? This is a bit unnecessarily sensationalist or alarmist is it?

I can't even begin to understand how you would ever need to hack core. Multi-site requires a sub directory and a small array in sites.php. Quick, simple and painless. Please correct me if I'm wrong, perhaps hacking core is required with D8?

It requires custom settings as well as highly advanced customizations and custom code changes

My first project weighed in at around 1600 lines of code in a custom module (inculding various controllers, plugins, yml etc) which wasn't so much about extending or creating wonderous functionality but about fixing issues and filling in the gaps. Views page titles and metadata, everything to do with emails, making contact form work nicely, preprocessing, preprocessing, preprocessing etc.

Sadly this is on a mostly static website. Hows that for "highly advanced customizations and custom code changes"? All I want to do is create a website not utilise an advanced deployment method.

This is just how Drupal is. Isn't it?

…because the fundamental idea is obsolete to begin with.

I don't think I agree but in either case as mentioned multiple times this has been leveraged by many large Drupal houses. This is a definite reason to use / not use Drupal. This seen as a pretty basic function of CMS these days so I'm not sure how this could ever fit well when Drupal is sold on it's functionality and scope.

-1
I use drupal multisite for a few years now. My main concern is because with this feature, you can have so much site with just one shared code base, on a small box. I am agree if we need to make the documentation better or the need to change the technical implementation of multisite. But to completely remove this on D9, I am afraid this will make drupal lost a lot of user (education market especially).

-1000

I maintain a 150+ multisite Drupal-as-a-service setup for a university. While I agree that multisite installs can be messy, I don't see a compelling reason to remove it.

Without getting into the details of our specific setup, as it is very highly customized to fit into an existing web hosting platform, we've devised a way (using symlinks, creative .htaccess rules, and some duct tape and bubble gum) to host all of these sites from one large setup. Individual site owners have full control over their themes and can enable/disable modules as they please, but we maintain the core installation and all the modules in one central location, which is all tracked in git for audit purposes, making it effortless to track security updates while preventing our less-than-technical site owners from breaking their sites. When someone wants their site "drupalized," we run a script and they're ready to go in minutes.

Since we don't use Drupal for URL routing (hence the need for symlinks and duct tape), we are able to avoid the issues of breaking sites during upgrades by simply maintaining separate "builds" of Drupal. We store our site directories outside of the core install and point symlinks to them from the current build's sites directory. We upgrade sites one at a time by updating the site's .htaccess to reflect the new build location and then running update.php.

Without multisite, I'd have to have close to 200 individual Drupal installations to maintain. I wouldn't be able to isolate these installations from the site owners (i.e. content owners). Experience tells me that many of them would apply every update they saw to production, without any testing, so not only would I lose control over the codebase and not know what updates needed to be applied where, I'd also have to spend a lot of time fixing things they broke.

Case in point: last week we got a ticket asking to have an arbitrary module updated to the latest version. We checked the module's page and found that we already had the latest version for D7 installed, but there was a newer version for D8, which it turns out is what the client was asking us to install. If we didn't have the multisite, he'd have tried it himself and would have broken his site...and then it would have been my team's problem to fix.

I agree that the current multisite platform is not perfect, but it is widely used and is very important to many of us that use it. If it was getting in the way of moving the project further, I could see the case for removing it, but as far as I can tell, it isn't. In the nearly 10 years that I've been using and supporting Drupal, I can probably count on one hand the number of modules I've encountered that don't work with multisite sites, and those typically happen because a developer didn't follow best practices and hard-coded a path in the code, which is easily patched.

The most compelling point in the OP's list is the use of shared tables...shared tables are risky, no argument there. But shared tables are a tool that can be useful to those who know how to use them properly. To put it in perspective, I have all the tools I need to rewire the electrical system in my house, but I'm not about to try doing that because I'd have no idea what I was doing. At the same time, though, I'm not going to call for a ban on screwdrivers and wire cutters.

The BOF session got scheduled at DrupalCamp NJ, https://www.drupalcampnj.org/program/sessions

And to be really clear, I don't want to debate the issue during the BOF. This so we can really understand why people use it, and what benefits they get out of it. The outcome of this will be a set of user stories / personas like,

"I run a SaaS, and multisite helps me by ..."

"I am responsible for websites in higher-ed, and multisite helps me by ..."

(Not exactly those, but you get the idea).

We can then use this information to inform the future of multisite. For all we know, there may be a solution out there that fits all of the needs that doesn't exactly look like the current implementation of multisite.

1. As a website builder, I utilise multi-site when a client has multiple brands (and domains) in similar or the same industry because each website has almost identical requirements. Multi-site massively reduces maintenance requirements and build time.
2. As a website builder, I utilise multi-site because I have a niche client base which have the same requirements. As above multi-site reduces maintenance requirements and deployment time.

I am responsible for websites in higher ned, and multisite helps me by getting sanity in

• Having different folders per environment
• allows me to put certain sensitive data, e.g. config out of the default git
• allows me to map multiple domains to a certain folder

In short: default is used for local, 'dev', 'test' and 'live' are used for domains on publicly accessable places (sometimes protected by .htaccess like .dev). I gives me sanity over which settings (e.g. many api keys, connection params to external services) in different settings.php files instead of having one big settings.php with a lot of logic. Also, some info is only available for key people who own the project or are able to generate certain keys.

So, removing this feature ? No no no. I think there's no sudden outbreak of common sense here, the only one here would be simply to close this issue and move on because this really works perfectly.

The maintenance for multisite is relatively minimal compared to a lot of other features in core, and it's clear plenty of people are using it.

Since there's no-one on this issue still arguing for removal, I'm moving this to 'works as designed' for now - someone can revive it if they really want to argue the case for removal.

There are other issues around like making the behaviour opt-in (to save a few cycles in bootstrap etc.) which could simplify some of the code we have.

And honestly, if the documentation isn't up to snuff then lets improve the documentation. As the saying goes - don't throw the baby out with the bath water.

here here @DamienMcKenna. Maybe instead of having 'multi-site debates' that are recorded at Drupalcon / camps and then go no where, we could all update the documentation page / what gets included w/ references to multi-site in core so that people can better understand the traps, implications and use-cases as opposed to "this allows multiple sites to live in 1 codebase" which is about all it says last I looked.

I created #2847218: Improve documentation around the multisite functionality.

Should we create a follow-up issue to specifically discuss deprecating shared tables in multisite? It seems like there is at least a consensus that it's not a best practice. I'm not sure if it removing support for it would reduce tech debt or simplify anything...

Not in disagreement w/ that though it would make multisites require having a unique database each / dropping the table prefixing capability (which I believe was created in order to satisfy the capabilities associated with multisite hosting on shared hosting). I have a hard time believing D8's even possible to fly on shared hosting as another vote in dropping that aspect. I also doubt it's much on tech debt.

Per table prefixing was already deprecated in #2551549: Deprecate per-table prefixing. I think we could deprecate prefixing in general and require each site to be in own DB. That would be a big help for tools like Drush.

Testing uses multisite to create semi-isolated Drupal installations to test under.

If multisite leaves core it would need to migrate to simpletest and core would still need to support infrastructure like database prefixes.

True ... I think the assumption here is that multiple databases is a reasonable expectation in 2017, and even more so amongst folks running unit tests. Testing API should use a second database instead of prefixing.

Additional requirements will make it even harder to get people to start working with tests locally, a solid -1 from me for requiring another database to run tests.

-1

Recently we've developed a Drupal 8 platform with multisite architecture for an university. The organization is divided in multiple offices (teaching deparments, investigation groups, student support services…). Each of them requires a custom site to manage their web contents: events, news, forms, etc.

In the past all the sites (120 sites more or less) were coupled in an unique Drupal 6 installation simulating a virtual multisite (various content types to simulate distinct kinds of sites, one Drupal user for each site, hundred of roles to assign different privileges to users for publishing contents hanging from different menu items of the global contents architecture…). With that architecture they had a lot of difficulties to grow the platform: can't add specific features for some users, can't customize the appearance of a particular site without a lot of development efforts…

So multisite was one of the main features to use Drupal 8 for re-architecturing, migrating and re-designing the platform, because it suits perfectly to the corporative structure. We've developed some custom modules, themes and various installation profiles that enables required modules or themes depending of the site.

In our case all the sites are very similar in functionality terms (very similar list of modules and very similar appearance) but some of them could have special requirements (some specific modules or customized design). For the design, we have a parent theme with the common branding components (header, footer…), and some child themes of the base theme, that customise the appearance if neccessary.

So, it would be a big dissapointment that multisite would be deprecated. I agree that documentation may be improved, and shared tables is very tricky (anyway we don't use it). Also configuration management, and upgrade process in multisite environments could be improved. In our case we've solved upgrades combining automation tools like Ansible with some drush commands.

-1

This feature is absolutely crucial for many EDU institutions much like many of the other posters said. If it's a matter of poor documentation, I also propose documentation be improved. We have over 100+ sites across a few servers using multisite here with symlinks to use sites as subdirectories rather than subdomains. Generally the only difference is minor configuration items and the odd one-off hacky module. It certainly has challenges, but nothing that cannot be overcome with some guile.

Alternatively, perhaps better support for multisites could exist at core by changing the approach. The feature is important to many and it offers benefits in hosting as many others have already commented. It absolutely has its place.

If the root problem is that it doesn't work with Composer, then maybe Composer isn't the right tool to be using in the long run. This may sound blasphemous, but if a tool dictates the work done it becomes hindrance. If it's the upgrade process that is problematic, then perhaps a better upgrade process should be looked at.

Just hopping in to add my -1 to removing multisites in general, but a huuuuuge +1 to not allowing shared databases (and making tests work by a secondary database).

If the root problem is that it doesn't work with Composer, then maybe Composer isn't the right tool to be using in the long run.

Composer probably isn't going away, but there is a possible solution here: #2845379: Provide optional composer integration but don't force users to understand how to use composer. Interesting quote from that issue:

Mixologic and I discussed this, and agreed that the right solution is to offer a rewritten Update Manager that embeds Composer (basically shipping with updater/ next to core/). That way people either use Composer, or they use the UI which runs Composer and then moves the changes into place. We also get core updates for free.

We use multisite installations daily we run over 900+ websites within two multisite containers. I can't imagine using Drupal without multisite. I think its one of its strongest features.

I do think more work needs to be done on the Drupal 8 side to make this better. Contributing to Composer patches to make this work sounds like the right direction.

Just going to pile on here with another -1.

Use-case: specialized web applications, with SaaS hosting, serving many end-users with nearly identical features/requirements.

I am developing a Drupal-based farm planning and record keeping application called farmOS (https://www.drupal.org/project/farm).

This is a very specific, standardized, and curated distribution tailored for creating a record-keeping application for farmers. Similar to the way in which Open Atrium or Red Hen are very specific applications for project management and CRM, respectively. It is not intended to be used as a public-facing website (although there will be some public-facing capabilities in the future), so in this sense it isn't the "typical" use-case for Drupal. But this is another reason why Drupal is awesome! It enables things like this!

I am starting a business around hosting instances of this application for farmers, and I am also working with agricultural associations, service providers, universities, etc to set up multi-site hosting platforms of farmOS that they can offer to the farmers that they service. Drupal's multi-site capability is ESSENTIAL for this.

All the code is shared - the only things that are separate are the sites/* folders and the databases. BUT: In some cases, I have a farmer client who needs something very specific. It is great to be able to write up a custom module for them, and put it in their sites/[client]/modules folder, so it is NOT shared with the other sites hosted on the same platform. It sounds like this (and themes) is a big plus for Drupal in academia as well - shared codebase, with the ability for individual departments to customize. I understand this point in particular poses complications with regard to Composer - but it is a feature that still has value, I believe. Let's discuss the options - perhaps in a separate specific issue.

If your use-case for Drupal does not require multi-site, that's understandable - especially if you generally use Drupal to build very individualized and separate websites for different clients. But that is not what everyone is using Drupal for. I, for one, am excited to see Drupal become the basis of more applications like Open Atrium, Red Hen, and farmOS in the future. And I think that multi-site is a feature that can be really powerful in this regard.

-1 for me too, I use "multi-site" feature over more than 10 completely different website on one server and it works very well.
I also really appreciate that you can update all the site at once. It really saves me time.

-1 to the general idea of removing multisite completely.

This will be a big issue for many current setups which use multisites, there will be challenges in moving to new Drupal versions for these setups and also possibly a rework on hosting and devops front.

I agree that multisite setups have their own challenges, especially ones with shared database. But most people have found a way to get past them and make it work.

It would be preferred to have better documentation on a multisite setup and various configurations, so that people know the advantages and disadvantages beforehand.

-1 Personally, I have used Drupal in many configurations, and different CMS that either did not support or did. Multi-site and with different Drupal cores for each site. I have come to rely on multi-site due to the ease of updating Drupal core and the modules. Personally I have found Drupal to be one of the easiest ones to setup. Just depends on if the multi-site is folder based or domain based. Folder based multi-site can get tricky due to needing symbolic/shortcut links to the Drupal docroot, while domain work out of the box.

- Having different Drupal Cores for each site, I have found can case issues with updating the different sites. If only I could count the amount of times I have blown up a site trying to update each Drupal version independently. (prior to composer)
- Multi-site makes it easier for upkeep with updates because you are looking at one location. Yes with the addition of composer this makes it easier, but not everyone can run that on a site or have the infrastructure to maintain multiple potential code bases.
- As far as shared tables, this should be addressed as not part of the standard norm without a prefix or a separate database for each multi-site. This is an area that would need expanded documentation. In builds, I have a tendency to use different databases.
- Documentation is limited, but that is due to not enough people understanding how multi-sites should be setup.
- Sites folder is great because you can segment what code is used for each site. On some installations, I do not use default unless the multi-sites is built off of the main site.
This would be for different domains, sub or full, running on one Drupal installation. ie: example.com & domain.com in multi-site
- Some sites can blow up, especially if update.php is not run on the different mulit-sites. Or the drush commands pm-update (pm-updatecode & pm-updatedb) are not run instead. But this is more of an knowledge issue and needs to be well documented
- Just using symlinks for each site and not having a way via the code to distinguish between which database or prefix should be used can cause other issues.
Then we are relying on code once again to determine this. Plus if you have one site that requires a contrib module X, and another to use contrib module Y, they both will have to be installed in the same module directory. Unlike current were you put it under that domain sites folder. This would create additional documentation and added code to resolve.

Currently I maintain multiple sites and different code bases spread over multiple servers using the multi-site setup. Mainly it depends on the client or group I am doing the work for on were the code/server lives. But if they have no preference, it goes into my current multi-site so that I can update all my sites in one shot.

Overall the fact of multi-site is a blessing for sites that want to have different portions segmented. Here is a classic scenario that I have seen many times.

Company XYZ asks for a site redesign to include a blog/forum. The site will be xyzdomain.com and the blog will be hosted on blog.xyzdomain.com

If they have a current site setup for this, it has two different CMS to handle both portions or are the same CMS. If they are the same CMS, most of the time one is kept upto date while the other is neglected.

My suggestion is to use a multi-site setup with a CMS, normally Drupal, to limit the code that needs to be updated or changed.

As far as integrating composer into the update manager, this is a great start, but may not be available for all to use. For example, Acquia servers use a git repository with the docroot being read-only. So the website will not be able to update core and modules. These changes would need to be done and committed through the code repository.

-1

The fact that Composer and multisite don't play well is annoying, leaving the simpler of choices: using Composer for managing site themes/modules and having them all shown as available in each site's UI, livable but confusing and cumbersome, or not using Composer for that.

Removing multisite would be much more than just simply annoying. It would be disruptive and costly.

-1
I am responsible for over 600 government site. Last 2 drupal security updates were really time sensitive. The value of updating the core once and affecting many sites is huge to me.

The problem of the Drupal multisite feature is not the feature in itself but what it does not offer natively compared to other CMS, see #2996988: Consider adding "Domain Access" (or equivalent) to Drupal CMS

-1
Multisite it’s not just a ‘cute feature’ — its a fundamental part of the system.

I don't think we need anymore -1s here; this issue was already marked Closed (Works as Designed) (meaning we're not planning to remove the feature) by catch 2 years ago in https://www.drupal.org/project/drupal/issues/2306013#comment-11887167, based on the valid uses cases outlined here.

Thanks for clarification!
This was brought up in one of my team chat this morn, probably is resurfacing as people are looking at what may change for d9.

Folks: The follow-up to this is #3004496: Document best practices for multisite and composer.

One question that's come up in that thread is how important the multisite features of a) per-site modules/themes (versus having all modules/themes in the sites/all directory regardless of which site they're used on) and b) installing the same module but a different version of it in a one-off site is to multisite users. See #3004496-68: Document best practices for multisite and composer. These are much harder to do under Composer, so we're trying to get a sense of how commonly used those features are, and since there are lots of people here who care deeply about multisite, would love your feedback!

There are absolutely both of those features in use in our environment and the reasoning for so is as follows:
a) Something custom designed for one particular site that no other site would ever use / a theme that will only ever be used for a single site. As soon as it crosses the threshold of 'absolutely no other site will ever use this' it goes into all.
This one is certainly less important in the grand scheme of things for our use cases with some additional permission sets and such.

b) There was an issue with some combination of date, calendar and views relating to ISO weeks that needed a patch for functionality that exists on a single site to function correctly. Patching the module in all would have broken some functionality on other sites that the one particular site was not using.

The other use-case for b would for direct comparison between vX.0 and v(X+1).0 modules without affecting all sites on the same server.

I am arguing in favor of multi-site, because: government. I work for the state of Tennessee and we have sites that need the ability to share a database, common elements and modules, and yet still be different for content moderators, and the general public. I think our biggest argument in favor of multi-site is the tedious process of doing security updates to Drupal (which has been nearly a weekly occurrence in 2019 for Drupal 8).

Secondly, the bullet points in OP's issue are less than worthy of a reason for deprecating multi-site entirely from Drupal.

1. So what if multi-site is older than 10 years???
2. Lots of things have poor documentation - it doesn't mean we throw them in the trash.
3. IF setting up multi-site is difficult, help make it better.
4. Agreed, you should not have to hack core. Help make it better.
5. Help make it better.
6. Help make it better.
7. No its not. Help make it better.

Not happening!
Multi-site stays!
https://twitter.com/Dries/status/1161379269043458050

An interesting way to improve multisite: https://www.flocondetoile.fr/blog/small-sites-large-sites-micro-sites-dr...

#101: While Micro Site looks like another good multi-tenant option alongside Domain Access, it's not a multi-site architecture. If you want that kind of architecture (as mentioned earlier), you need Aegir, which isn't really single-tenant. It's more of a hybrid because the code is shared (sites can share a "platform", Aegir-speak for a Drupal code base). I prefer this architecture because it allows for data portability: If a customer wants to leave, you simply hand over her database. Customer data doesn't overlap. So it's cleaner that way, but it's true that there are more moving parts.

If you're interested in this or the Drupal SaaS space more generally, I'd recommend keeping an eye on Aegir Site Subscriptions and related modules (like Aegir Services).