Contrib.social

Improve multisite compatibility with composer

Open on Drupal.org →
Created on 4 October 2018, almost 7 years ago
Updated 19 August 2025, 4 days ago

Problem/Motivation

Now that we've adopted Composer as a build tool for Drupal, we're left with some features of drupal that still need adaptation and engineering to work.

Multisite Drupal is an extremely useful feature for many sites, and the consensus is that its a critical feature that cannot be replaced with multiple single sites.

Let's use this issue to do 2 things:

1. Document what multisite is, and the use cases people use it for. i.e *why* do people need it, and *how* do they use it?
2. Brainstorm potential solutions and look for a path forward that allows a multisite user to be able to use any of the modules that have 3rd party composer dependencies, and allow them to update and mange their site with composer.

Proposed resolution

Still TBD. The trickiest use case to support with Composer seems to be a multisite where there are variations of modules/themes on a per-site basis. (For example, someband.com and someotherband.com offer the same features [photo gallery, discography, tour], but have vastly different designs, and/or someotherband.com has an integration module with some one-off analytics application that no other sites want/need.)

This gets tricky because modules + themes are individual projects in Composer, and Composer assumes there is only one location all dependencies are going into. (By default /vendor) This is incompatible with the idea that there are multiple places to look for extension code (sites/all + sites/someotherband.com)

Possible ideas that have been tossed around:

  • #17 🌱 Improve multisite compatibility with composer Active : Move forward with the Composer initiative, not accounting for this use case for now (and documenting such), and work upstream with the Composer project to handle it in a generic way for more than just Drupal.
  • #20 🌱 Improve multisite compatibility with composer Active : Use Composer's ability to override installer paths on an individual package level, along with custom magic in our autoloader, to place some code in different directories. However, there are quite a few downsides to this plan, as documented in #22 🌱 Improve multisite compatibility with composer Active .
  • #36 🌱 Improve multisite compatibility with composer Active : Add a composer.lock and vendor/ directory to each /sites directory, similar to how you can add a per-site /modules or /themes directory currently. Requires adjustment to the autoloader, possibly other things, but is consistent with the current approach.
  • Others?

Remaining tasks

  1. Captured at https://www.drupal.org/docs/8/multisite/use-cases-for-drupal-multisite →
  2. Brainstorm potential solutions and look for a path forward
🌱 Plan
Status

Active

Version

11.0 🔥

Component

composer

Created by

🇺🇸United States Mixologic Portland, OR

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 4 days ago →
    🇭🇺Hungary nevergone Nyíregyháza, Hungary, Europe

    How could this be moved forward?

  • Comment 3 days ago →
    🇺🇸United States greg.1.anderson

    I think that the best path to resolution is to aim at meeting the two goals of this issue (1. document what mulitsite is, 2. recommend code management strategy) following existing practices.

    - Document the recommended code management strategy for multisite is to use Integrated Composer
    - Accept the limitation that the *code* of every multisite is always the union of the dependencies needed by all of the multisites.
    - Accept that the previous limitation also implies that every multisite must use the same version of any given dependency they need.
    - Each multisite can choose to either enable or not enable any given available module.

    Allowing different versions of the same dependencies in different multisites requires too large of a perturbance of core Composer assumptions. Attempting to work around these assumptions at the application layer (e.g. #90) is ill advised. Keep it simple and move forward using what we already know.

  • Comment 2 days ago →
    🇬🇧United Kingdom catch

    Yes #108 make sense to me as well.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024