Changes coming to Config Split

Help to decide the direction of Config Split

Config Split has worked mostly the same way as it did when the first beta release was tagged in 2016. The 8.x-1.x branch is using Config Filter as the API to hook into the configuration management of Drupal. But since Drupal 8.8 we have a much better API in Drupal core which allows us to do more complex things with simpler code than the Config Filter API did. The core API was designed with the lessons learned from Config Filter in mind after all.

Config Split 2.0.0-beta2 already uses the core API, but it still does the same thing as Config Split 1.x. I think now would be a great time to change things up a bit and do the things that were too hard to do before.

But first let's revisit what Config Split does.

On export these two things happen:Complete Split:
Modules and config and all the config that depends on it is split off into the split storage and removed from the sync storage when the export is complete.Conditional Split:
The config is compared against the sync storage and is split to the split storage if it differs, the original config in the sync storage remains.

On import the config from the split storage is merged before Drupal imports the config from the sync storage.

Now what do I propose 2.x should do?

On export these very similar but different things happen:Complete Split:
Modules and config are removed from the sync storage as if it had been uninstalled. The difference of how other config (which no longer depends on the modules) changes is kept as a quasi-config-patch* together with the config of the split modules in the split storage.Partial Split:
Config is compared against the sync storage but instead of splitting the whole config to the split storage only the difference is kept in the split storage as a quasi-config-patch*.

On import the config from the split storage is merged and the quasi-patches applied before Drupal imports the config from the sync storage.

What now?

I think these changes make sense and make Config Split a better module. But the behavior is quite different, so if you have gotten accustomed to the stability of Config Split and depend on some specific way it works then this could be upsetting. And right now there is still a way to have the cake and eat it too: We keep 2.x the way it is now (in beta2) and maintain the behavior and only add "non-breaking" changes and do what I proposed in 3.x. Here is the catch though: I am not interested in supporting two branches, especially if I don't know that it is useful to anyone.

Please let me know what you think about this in a comment on the issue on drupal.org.

* What is a "quasi-patch" or a config patch?

The word quasi-patch was already introduced to the drupal world #3055872. But what I have in mind is a bit different. I think it will be easiest to explain with an example:
Imagine you install the demo Umami profile and then uninstall the Menu UI module. The recipe node type will be updated to have the third party configuration removed. A patch for the exported config file would look like this:

diff --git a/node.type.recipe.yml b/node.type.recipe.yml index 974c2ce..8d0de1f 100644 --- a/node.type.recipe.yml +++ b/node.type.recipe.yml @@ -1,13 +1,6 @@ uuid: 40b74b76-6f31-4999-87bb-9700b85d43a6 langcode: en status: true -dependencies: -  module: -    - menu_ui -third_party_settings: -  menu_ui: -    available_menus: {  } -    parent: '' _core:    default_config_hash: '-3P1yuM15pcimXHBBhevjW-4aqojpmZbUgAqlVIeweo' name: Recipe

The quasi-patch or config patch would be a file called config_split.partial.node.type.recipe.yml with the content:

added: {  } removed:   dependencies:     module:       - menu_ui   third_party_settings:     menu_ui:       available_menus: {  }       parent: ''

Disclaimer: The details about this are subject to change. There are likely some compromises we need to make.

Tags: Drupal PlanetConfiguration Management

Original Article:

Changes coming to Config Split