Updated: Comment #30
tldr; The key point here is that configuration sync currently does not work because providing UUIDs in all config entities created during module install is not possible. In order to make config sync work we need some way to have a site which has config entities with UUIDs that match the source site.
If you want to be able to do this now - checkout https://www.drupal.org/project/config_installer
The configuration management system needs to support the following requirements:
Requirement 1: the ability to install two Drupal sites and sync configuration between them
This is the basic CMI requirement. In previous versions of Drupal people have been accustomed to getting the code, files directory and the db to recreate a site to work on. In Drupal 8 we're aiming to be able to only require code and the configuration files.
Requirement 2: the ability to determine if a configuration entity has been deleted and recreated OR just updated
This is especially important for fields. As updating will not destroy data but delete and create will cause a field to be purged.
Requirement 3: the programmatic creation of configuration entities during module enable
During a module enable we need to be able to create configuration entities without providing default configuration. Imagine the following scenario:
- Enable a contrib module that implements a hook to create a config entity when a node type is created
- Enable a module that creates a node type - there is no way this module can provide default configuration for the config entity that will be created by the contrib module!
For more information read
Solutions already explored / currently half implemented
In order to support requirements 1 and 2 we added default UUIDs to all configuration entities. This means that it was possible to sync a standard install to a standard install because all the UUIDs were the same. However the requirement to support 3 rules out this solution because you can not provide default UUIDs when the configuration entity is created programatically during a module enable. We explored using predictable creation IDs instead - however this means that under certain circumstances you can no longer satisfy requirement 2.
Why creation IDs can not support requirement 2
If they are based on config entity name:
- (On dev) Enable a module that provides a default config entity (eg. a field) called bla
- (On live) Deploy this configuration.
- (On dev) Disable module and delete the default config entity bla.
- (On dev) Enable another module that provides a default config entity (same type) also called bla
- (On live) Deploy this configuration - this will then try to update/rename the bla config entity because the creation IDs will match whereas it should do a delete and recreate.
If they are based on [config entity name + providing module], then in turn it means you cannot reorganize your default config within your modules (aka "reorganize your Features in D7).
For more information read .
Add a new install parameter
existing_config. If this is set to 1:
- The modules enabled during installation are calculated from the system.module.yml in the staging directory
- Configuration entities are not created during module install
- A new install step enables any themes based on system.theme.yml in the staging directory
- A new install step syncs the configuration from staging to active
- A new install step presents a form to create a maintenance user
How this meets the 3 requirements
Requirement 2 means that we need a way of installing Drupal using the configuration from an existing site so that the configuration entities created will have matching UUIDs. We can satisfy requirement 3 during the site install by using the same process we've developed for regular configuration sync - the isSyncing flag. Once we have a site installed using configuration from another site we can easy satisfy requirement 1 because we know that any change in a UUID represents a situation where we have delete and create.
Additionally implementing this means we can remove default UUIDs from the all the default config entities which has been discussed at lengths with @sun, @chx and myself thinking that it is extremely risky to use a UUID for something that is not unique as it will be the same on every Drupal 8 site installed.
User interface changes
So far all the change could be classified as API addition.
- New functions in install.core.inc to support the new steps
- New form in installer to create site maintenance account
- Add ability to synchronise configuration using a batch.
ConfigImporter::import()accepts an number of configuration objects to process.
Original use-case description by @sun:
- I'm starting to develop a new Drupal site from scratch on my local machine.
- I upload all of the code and config to my remote web server (or using my $vcs of choice).
- Stuck. I'm only allowed to install a new site with new profile/config from scratch.
- Allow to install a site using existing configuration.
- Enable the Drupal installer to install a site from existing configuration (if any), instead of an installation profile.
- Add an installer screen to choose whether to install from existing config or from scratch.