David López, Ricardo Sanz: Sharing configuration in multi-site and multi-profile platforms
Drupal critics used to say it turns developers in a sort of click-monkeys.
In fact, most of the things in Drupal are configurable, but we need a solid way to deal with all that configuration.
On the other hand, Drupal has installation profiles and this let us have a good start point for our new websites, and also let us have a sites galaxy (related or not between them) with similar functionalities.
Since Drupal 8, we are able to export the configuration to code, and the YAML representation of the configuration also made easier the development of installation profiles. Drupal supports natively this way of representing any configuration.
From Drupal 8.6 had born a new way of installation, called "installing site from existing configuration".
This new installation way is described as being for development purpose but, What happens if we move it to production?
It opens the doors to a new way of understanding installation profiles, based on a shared existing configuration, allowing several differences between sites by context. With this approach is possible to have tens (hundreds?) of sites sharing the configuration on a single central point where a single configuration change can be easily applied (or not) to all of them simultaneity, being also available immediately to the future created sites.
This includes:
- Installation profiles based on existing configuration.
- Installation profile inheritance.
- Multi-site installations with shared configuration.
- Multiple installation profiles with shared configuration and codebase.
- Usage of config_split by the environment, site, installation profile or installed module.
- Override configuration for specific sites.
- Practical code examples to do that.
- Good and bad things about this approach.
- CMI 2.0 and future.
https://cluj2019.drupaldays.org/sharing-configuration-in-multi-site-and-multi-profile-platforms-a-modern-oddysey
In fact, most of the things in Drupal are configurable, but we need a solid way to deal with all that configuration.
On the other hand, Drupal has installation profiles and this let us have a good start point for our new websites, and also let us have a sites galaxy (related or not between them) with similar functionalities.
Since Drupal 8, we are able to export the configuration to code, and the YAML representation of the configuration also made easier the development of installation profiles. Drupal supports natively this way of representing any configuration.
From Drupal 8.6 had born a new way of installation, called "installing site from existing configuration".
This new installation way is described as being for development purpose but, What happens if we move it to production?
It opens the doors to a new way of understanding installation profiles, based on a shared existing configuration, allowing several differences between sites by context. With this approach is possible to have tens (hundreds?) of sites sharing the configuration on a single central point where a single configuration change can be easily applied (or not) to all of them simultaneity, being also available immediately to the future created sites.
This includes:
- Installation profiles based on existing configuration.
- Installation profile inheritance.
- Multi-site installations with shared configuration.
- Multiple installation profiles with shared configuration and codebase.
- Usage of config_split by the environment, site, installation profile or installed module.
- Override configuration for specific sites.
- Practical code examples to do that.
- Good and bad things about this approach.
- CMI 2.0 and future.
https://cluj2019.drupaldays.org/sharing-configuration-in-multi-site-and-multi-profile-platforms-a-modern-oddysey