search

computerminds / cm_config_tools

DEPRECATED: Mirror of http://cgit.drupalcode.org/cm_config_tools
1 stars 0 forks source link

Investigate/fix overriding externally-provided optional config #23

Closed anotherjames closed 7 years ago

anotherjames commented 7 years ago

See https://github.com/computerminds/cm_config_tools/issues/16#issuecomment-262297798.

My response:

So I think the actual problem here is that overriding something in another module's config/optional with something in a cm_config_tools-managed module/profile's config/install directory does not work correctly. I suspect simply having the view in our profile's config/optional dir would suffice, no need for core patches. I could be wrong, so I'll test.

...but to be honest, that's still a bit weird/icky, we should make it ok to override config that was in one module's optional directory by putting it in a cm_config_tools-based extension's install directory without problems.

anotherjames commented 7 years ago

I've just tested this... but I cannot reproduce the problem, under the latest cm_config_tools. I'm going to revert to the codebase at the time that had the problem and try again.

anotherjames commented 7 years ago

I cannot reproduce the problem that had been occurring. The more I look into this, the more I believe the problems were either caused by:

1) Using an outdated version of cm_config_tools, or other project dependencies. 2) Not following the suggested workflow (for example, I notice that the views.view.taxonomy_term config item contained a UUID)

So I think that the original problem has since been resolved (either by updates to cm_config_tools or other projects, or by improvements / better experience with our own workflow). To be honest, I think therefore we should remove the core patches that we put in as a workaround, but I guess we can leave those in if we're concerned.

But I think this should no longer be considered a bug in cm_config_tools or our current workflow.

@darthsteven are you ok with that conclusion?