In current versions of Drupal, you can configure a multisite install to arbitrarily specify what configuration is shared through table prefixing. For instance, you can have the roles table shared but nothing else, and all your sites will share the same roles but each will be unique for everything else.

This is not currently possible with CMI. Tables can still be shared, but we do not have this concept in CMI. This is (probably) a critical regression right now. Some options

1) Won't fix. We decide that you just can't do that with CMI and punt the problem to Domain or other contrib solutions.

2) If we keep the context system, we can either build context plugins to manage this. This would probably be the sanest approach, however there is currently an issue to remove the context system (#2098119: Replace config context system with baked-in locale support and single-event based overrides) which seems reasonbly likely to land and I don't think this is a compelling reason to block it.

3) Implement something new. beejeebus and I discussed an idea that there would be a hierarchy of overrides, and default config gets merged into the levels above until you end up with a full set of overridden config. For instance

1) $conf
2) sites/[site]/config/active
3) sites/[default]/config/active

There may be more levels. We discussed having an event which could inject overrides as well, but I feel icky about this. Regardless, this is one idea of what we could do. There are probably others.

Discuss

Comments

heyrocker’s picture

We could solve caching the same way it is proposed in #2098119: Replace config context system with baked-in locale support and single-event based overrides - take all the possible overrides and concatenate together for a unique cache key. So you could have

[config_name] - no overrides
[site]:[config_name] - running multisite
[language]:[config_name] - running a multilingual site
[site]:[language]:[config_name] - running a multilingual multisite

Traditionally this has been around the time when people start saying we need a context system. The problem is that with unlimited contexts you have nfi how to cache. At least this way we can do what we need to with a known set of possible overrides.

heyrocker’s picture

Issue tags: +Configuration system
catch’s picture

I'm not sure table sharing/config sharing is something we should continue to support. In my experience when that's used, it often goes wrong.

For example you might share a table, but not share one or more cache bins that in some way have cache items that depends on the table - so when the table is updated on one site, the cache bin on the other is not.

On the other hand if you share the cache bins that are affected by a shared table, they might have cache items that depends on different, non-shared tables too, and then you get conflicts between those.

Since we allow arbitrary cache items to be put into any cache bin, there's not really a nice way around this - you can have a custom cache backend which clears different instances of the same cache bin but only reads/writes from one (which works until you have something trying to do write-through caching).

Building up the correct cache key isn't necessarily enough - you still need to know that the config cache table needs to be shared, or hack something up with a shared memcache bin and no site prefix, and then there's all the non-config cache bins that depend on that configuration.

Those are existing problems, and it only gets worse once CMI comes into the picture I think, domain, organic groups and similar modules are a better approach now.

One thing we can/do support is $conf overrides in a global settings.php - which can currently be done via sites.php iirc but it's not obvious. That allows some configuration to be shared at least even if it's not CMI files.

Agree with this being critical though, even if it ends up won't fix we need to resolve it.

catch’s picture

Title: Make CMI work with multisite » Make CMI work with multisite and shared tables
Category: bug » task
catch’s picture

Issue summary: View changes

Updated issue summary.

alexpott’s picture

I was wondering where or not symlinks might offer a solution?

heyrocker’s picture

I'm trying to think of how that would look. Individual sites would *probably* look for config in their sites/[site]/files directory, since that is what I believe conf_path() returns. So as long as when you setup the new site you also copy the active config from sites/default (which normally you would, since IRC is telling me the process is just cp -r sites/default sites/newsite) then things should work fine.

As far as sharing, in this scenario, you would need to delete and symlink any config you wanted to share back to its version in sites/default. To deploy you would need to check the symlinks into git, I know this is possible but I don't know the implications of it.

We would still have to deal with the caching implications, but I think that appending the sitename to the cache key would manage that.

This is worth testing, but if that setup actually works, then apart from the cache key this would just be a documentation issue. Put this in stone as the standard procedure and wipe our hands of it. This would make me very happy and I would be totally fine with it.

Berdir’s picture

cache keys don't need to have the site name in them, because caches are always for a specific site. That's like putting "Drupal" in them ;)

You can't share the database tables (well, you could and it would result in *very* interesting scenarios), and that's why cache backends like Memcache have a built in global cache prefix that you have to configure if you use the same memcache instance for multiple sites.

As described in IRC, this is IMHO a non-issue. If you want to share configuration, then all you have to do is come up with a custom (manual or not) to copy the relevant files into each staging folder and then import it. And if all sites should have identical configuration, you could use the same staging directory for all of them ;)

I don't see a use case for doing anything more and this IMHO already gives you much easer and fine-grained control than you had in 7.x (You could either share the variables table or not, and not control which values, for example).

catch’s picture

Priority: Critical » Normal
Issue summary: View changes

Yes agreed this has never worked, and if anything it's better in 8.x than previous releases. Downgrading to normal - it'd be good to document some options similar to what Berdir describes but I don't think we need to do anything more.

heyrocker’s picture

Beejeebus did some tests with symlinks and it also worked as expected. So I agree we have plenty of options and this is really just a documentation task.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.