Config split with pull

Hello! I've been unsuccessful and wondering if someone could help me identify what I'm doing wrong.

My project is on v2.0.0-rc4 on this module.

I consulted this issue and https://www.drupal.org/project/config_split/issues/3167216 → and took the following steps on my local development environment, built from a copy of my project website's production database (which currently has all splits configured to use "Folder" storage method):

1. Updated the local settings file to activate only the production split, then cleare cache
2. Updated the production config split configuration to use the "Collection" Storage method instead of "Folder" using the config split configuration UI
3. Ran drush config-export and could see that production split config was being written to the following location: config/sites/default/split/[split_name]/ where config/sites/default is our sync directory.
4. Moved the contents of our prior config split folders (config/config_split/[split_name]) inside of these new split collection directories (config/sites/default/[split_name])
5. Updated the rest of the config split configurations (we've got local, development, staging, production) to use the "Collection" Storage method instead of "Folder" using the config split configuration UI
6. Attempted to export config with drush cex and found that the config belonging to all non-production splits/collections
   (ie. non active) or not belonging to the config sync directory was deleted. (except some of the config patch files for some reason).
7. Alternatively ran drush config-split:export production and found that the config for that split exported, other splits are untouched, but didn't have a way to export the shared sync config

I'm wondering if we have to reimplement config split from scratch with this collection storage method instead of attempting to switch after already using the Folder storage method? Or if I'm misunderstanding something fundamental about how collection storage should work and the new collection storage directories aren't meant to all exist at a given point in time?

Any further documentation or guidance would be appreciated. Thanks!

You did it mostly correctly.

The thing is that when you switch the split storage location in the UI, the split needs to be active in order to participate in the export. The configuration of inactive collection splits is kept in the active config table in the collection and when inactive config split doesn't touch the split or its collection, so it gets written to disk as is (and as expected by users). (in your case the split was inactive and didn't exist as a collection in the active storage, so it got removed from the file system because after an export the file system is supposed to reflect how the active storage looks like.
If you move files around in the sync directory (ie outside of drupal), you also have to change the collection location in the split yaml, and then import the configuration with the split directory moved.

Basically if you do something in the UI you then need to export the config, if you do something in the file system you then have to import the config.
And you should keep in mind that only active splits participate in the config transformation (so being split to their directory on export and merged to the main config on import).

The fact that some patches remain is very strange and probably a bug? I would have to find out how this happens, so if you have a way to reproduce this in a "clean" environment or a test I would be happy if you could open a new issue.

@bircher thanks so much for your response.

I wonder if you could list the steps we'd have to take to convert our config_split setup from using Folder storage to using Collection storage with the goal of (on an ongoing basis) being able to have one active split per environment and being able to use config-pull to capture prod config in a different environment (like a CI container, for example).

If it's helpful, here's my attempt at generating a list based on your response, but I'm still unable to get the last step validated after taking these steps:

1. Make all splits active
2. Switch all splits to use the “Collection” storage type
3. Export configuration
4. Make only the split we want active
5. Export the configuration and we should not see deletions

Did I get the steps right?

I also have a couple of follow up questions from some parts of your response:

you also have to change the collection location in the split yaml, and then import the configuration with the split directory moved

Is this removing the folder path from the split configuration YAML or changing it to be the new directory? In the UI the field that populates this property in the yml is hidden once you change from Folder to Collection and I didn't notice a new field for collection location in either the UI or yml.

And you should keep in mind that only active splits participate in the config transformation (so being split to their directory on export and merged to the main config on import).

Does this mean that inactive splits will always be deleted (vs ignored) on export / import?

Some more context about what I'm experiencing:

On subsequent exports with all splits still enabled, there are still unintended updates to config in some of the splits where values would be overwritten with values from other splits (ie. config values from the development split are overwriting the came config in the production split).

Thanks again for your help!

@bircher thanks for taking the time to follow up with us. I'm happy to share that we were able to get this working. As you mentioned, the key was:

Do not have multiple competing splits active at the same time or they will get their values messed up. And Deactivate the split you don't want to be active rather than just changing the override in settings.php

We haven't gotten this scripted or automated this is our team's workflow just yet, but I can get all of the steps working myself manually. I'll follow up here with any new lessons once we do build this in.

Thanks again!