Configuration split is very inconsistent when and doesnt work as intended in many ways.

Here are a couple scenarios:

1.) When doing a drush cex it states what files will change. And with that it exports additional files that were not part of what was told would be exported.

2.) Some configuration that is not in the config split at all is being exported to the config split folder. Im not even sure how this one is even possible or how config split can even make this possible

3.) Configuration from one config split ends up in the folder of another config split item. Config split A has X configuration and Config split B does not. But somehow config split B ends up with X configuration thats suppose to be in config split A. This one baffles me to no end.

Comments

chadmandoo created an issue. See original summary.

brandonratz’s picture

I am also experiencing these inconsistencies recently. I have a few examples to reproduce I'm attempting to gather.

drush cex consistently shows the set of actual file changes but then performs an export of additional unrelated files.

I noticed this after creating a new empty split. All of my existing splits would move files around in other splits as if the new split conflicted in some way.

The most disruptive issue I've found is when creating a split who's directory doesn't exist. When running drush cex it will error (as expected) but then deletes your entire staged config and all splits.

naresh_bavaskar’s picture

Assigned: Unassigned » naresh_bavaskar
naresh_bavaskar’s picture

Assigned: naresh_bavaskar » Unassigned

About the question. 1.) When doing a drush cex it states what files will change. And with that it exports additional files that were not part of what was told would be exported.--> I have faced this problem while using config ignore module not in config split.

brandonratz’s picture

@naresh is correct. config_ignore will cause this issue and you should look into this patch https://www.drupal.org/project/config_ignore/issues/2857247.

In my case, I have config_ignore enabled but no patterns present.

brandonratz’s picture

I have deduced the majority of my issues to including certain keys in the splits.

First, wildcards have a perceived randomizing export behavior. For example, *.node.foo.*will result in collecting configuration from other referenced entities with dependencies on that node type.

Second, splitting the keynode.type.foo also results in perceived randomized export behavior. I also think this is due to referencing dependencies.

I have also discovered the above to be effected by the order of splits. Splits appear to export in alpha order if not explicitly set weights. This also changes the export behavior and which config is moved into unexpected places.

bircher’s picture

Component: Code » Documentation
Status: Active » Postponed (maintainer needs more info)

The issue makes very broad claims without any example configuration to back it up, so I am changing the status.

This module splits off configuration that depends on the configuration that you specify explicitly.

There are some discrepancies with what drush says will be exported and what is actually exported because drush only looks at the sync directory. This also changes between config_filter 1.x and 2.x. (and hence the major version change) In any case the split is exported also when you just view the diff and don't really export with drush. There is nothing we can do about this in config split 1.x and is something we can only address in config split 2.x.

Also splits are ordered, and if the first split splits something off then the second split will never know about it.

Re #6: Splits should be sorted by weight, if they are not that would be a bug. #3029666: Filter weights are not respected should have fixed that though.

So if you want help with setting up this module you should post the configuration that lead to it. Three years ago I created https://github.com/bircher/config_split_debug for the explicit purpose of creating an example that reproduces a bug. (it would have to be updated of course, but maybe we will be moving to drupalspoons so that will make things much simpler then)

Of course if you can demonstrate your bug with a phpunit test then that is even more appreciated and will help solve it more quickly.

chadmandoo’s picture

Thanks for the information I am circling back to this issue this week and will provide more updates as needed

joseph.olstad’s picture

I have the latest config_split , config_filter , not using config_ignore
and for some reason drush is not writing to the splits folder when expecting it should.
have tried changing the config split configuration over and over different combinations of options doesn'T seem to help

my dev split does not have these modules installed though,
live split does

I guess there's not a critical need to split these if they're not installed on both configurations however I was expecting it to split.

not the end if the world

other configurations that seem to be in both split configs do however go to the splits folder.

Must be default behavior?

joseph.olstad’s picture

*** EDIT *** ignore this

joseph.olstad’s picture

Ok I think I figured out how to reproduce this.

Install config_filter 2.2.0 with config_split 1.5 or 1.6

things get buggered up badly

to fix this (if using composer):

remove any mention of config_filter from your composer.lock file and composer.json file then composer require 'drupal/config_split:^1.6'

OR alternatively if you want to use config_filter 2.2.0 make sure to use config_split 2.x dev

I haven't completely tested all this but I believe config_filter 2.2.0 is NOT compatible with config_split 1.x and a bit confusing because there's no tagged release of config_split 2.x yet (not even a beta)

joseph.olstad’s picture

actually my configuration was also incorrect , I had a settings.local and settings php file , one was superceding the other so I thought my live was active but the dev was active

so check all this and also check the versions of config_split and config_filter you're using.
if on config_split 1.x use config_filter 1.x

if using config_split 2.x dev then use config_filter 2.2+

bircher’s picture

Category: Bug report » Support request
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I guess it was a problem with how the site was configured.
Don't hesitate to update the documentation on how to use this module if it is not clear enough.

joseph.olstad’s picture

Thanks ya it's working as expected! Great modules thanks!