Some issue when working together with config split

Sorry for never responding here.

This module does in fact not work correctly together with Config Split at the moment, unfortunately. I noticed this myself, as well.

In attempting to track down and fix the issue I realized there really is a circular dependency here which makes it impossible or at least infeasible to fix in the current form of the module. Fortunately 📌 Convert to a storage transformer Fixed will be committed soon and that will change things.

The problem is that depending on the use-case any or both of the following contradictory two statements may be true:

1. Because you want to ship configuration split files in custom modules and not have them in the sync directory you want Config Overlay to run before Config Split so that Config Overlay will overlay the splits and then Config Split can do its work
2. Because you are enabling modules as part of a Config Split you want Config Overlay to run after Config Split so that Config Overlay can overlay the module-shipped configuration of the modules that Config Split has added

So there is really no right or wrong, as far as I can tell. The good thing is that Config Overlay is inherently idempotent, i.e. just running the overlay process multiple times does not break anything (even if it is slightly inelegant). So the solution, as far as I can tell, is just to run the Config Overlay process before and after Config Split. Not sure yet, if before and after every config split or just once at the very beginning and once at the very end. But in any case, running multiple times is not really easily possible with the filter architecture. It becomes much more feasible with the new storage transformer API in core, so once that is in, this should become doable, maybe even trivial, let's see. In any case postponing for now.

I am not an expert of Config Split, however, so feel free to comment if I have missed anything or if things are not quite as I described.

Just merged 📌 Convert to a storage transformer Fixed . This means this may or may not actually be fixed automatically now, I didn't try it yet. Either way we should add a test for this.

Some updates:

• I tried it out now and the very basic functionality of splitting things out and having the import still work correctly seems to work now. I only played around with it very briefly, so there may be things that don't work, but something didn't seem to be the case at some point. I suspect that #2989520: Fix deleting shipped configuration entities → may have fixed something for this scenario, as well. But I'm pretty sure that shipping the config split configuration files in "overlayed" modules does not work.
• Because of the above I started writing a test for the integration to establish a baseline of what works, so we can add to the test when fixing/testing more things. I couldn't really get that to work yet, though. The config split transformer is called, but something afterwards seems to go wrong when exporting the config in the test, so the configuration is not actually split off. I will push my current state into a draft MR for now, not sure when I'll be able to pick it back up.
• Re-reading #3 again, I think 2. is not actually valid because Config Split itself takes care of merging the configuration of the modules that are split off. I had totally forgotten about that when writing that. Not yet 100% sure what that means, but maybe just changing Config Overlay to run before other transformers will actually fix everything here. Thinking about it now, it also kind of makes sense, contrary to what I wrote in 🐛 Incompatible with Config Ignore Fixed . Because Config Overlay makes the transformed storage look fairly radically different, maybe it is smart to "hide" that by reverting the "different-ness" and already having everything "back-to-normal" (i.e. including the overlayed configuration) before most other transformers do their work.

OK, good thing is that the issue was in fact an issue with the test and at least the basic case that is being tested here does in fact work. Didn't realize that Config Split doesn't actually write anything to a folder when "just" calling the storage transformer but only does that in a Drush hook. ...which of course doesn't get called in the test, so we need to re-create that behavior here manually. Doing that and some other smaller fixes makes the test pass.

Will merge this, but leave the issue open for:

1. Changing the event subscriber priority as noted above, so that Config Overlay runs early instead of late. Have sat on this for a bit now and it just makes total sense to me. Since Config Split allows specifying certain splits to be transformed with specific priorities via settings.php configuration, whether we maybe want that, as well, so that people can just specify the priority (or priorities, if they want to run the overlay multiple times) via settings.php.
2. Expanding the test coverage for splitting a module with configuration as well as overlaying a module with a config split. Not sure if there are more cases but that at least would make me confident in proclaiming the integration to be actually working.

Oh also just noting here, that I'm sneaking a fix for ✨ Use structured DSN instead of URI in system.mail mailer_dsn Fixed in here, as well.

OK merged, now so back to needs work per #7.

Just another note, that since Config Split has now released a stable, we can update the version constraint for the dev requirement...

Alrighty, finished this yesterday. Was a bit of a back and forth and also a bit unfortunate because I had just blindly assumed that Config Splits also reads the information about the splits itself from the transforming storage and not the active storage and that might have made things a bit more complicated in some cases but in the end a lot more elegant. I am also fairly strongly convinced that it's wrong that Config Split reads the active storage for that during the transformation, but presumably there are reasons for that and in any case that's likely not going to change anytime soon.

So basically everything mostly worked already since the transformer rewrite. Now changing the subscriber priority so that Config Overlay runs first fixes the issue that config splits are not detected on initial import. "Nested splits" (see https://git.drupalcode.org/project/config_overlay#nested-splits ) don't work out of the box on the initial import, but since Config Split reads the active storage (see above) that's easy to fix for people themselves so we don't need to work around that.

I was a bit disappointed that I thought there was no way to get the Config Split directories to not have "unnecessary" configuration (from the perspective of Config Overlay) until I looked at the "stackable" feature. So to support that now we actually run both before and after Config Split on both import and export. So while that's a slightly "brute-force" approach it's also not too inelegant because Config Overlay's operations are inherently idempotent.

So all in all, glad to have this fixed finally.

Having written this just now, I just realized it would be even nicer to dynamically add the "second round" of transform subscribers dynamically only if Config Split is enabled by putting them in a second service. Marking needs work again for that. That will alleviate the biggest chunk of inelegance which is that currently everything is run twice unnecessarily even if you do not have Config Split installed.

Alrighty implemented that now. Will mark this fixed, finally, and now on to tag a 2.0.0 stable version.

Just a note that I had missed the last commit accidentally when creating 2.0.0. Created 2.1.0 now to rectify that.

Automatically closed - issue fixed for 2 weeks with no activity.