Some config changes not being seen

This is likely in Configuration Synchronizer so let's start there.

This may be a bug, but let's start as a support request until we confirm.

I'll make this move and then follow up more.

We have a site set up with a piece of config that originally looked like this:

When you say "originally", what do you mean? Is this configuration that was provided by a module? If so, was it in config/install or in config/optional? Is this Yaml the full configuration file as originally provided? If it's not the full Yaml, can you give the full Yaml, and also note the file's name?

It now looks like this:

Again, where does it look like this? In the newer version of a file?

The config in question is in a file named config/install/webform.settings.yml. This is in a module exported by the Features module.

@Liam Morland thanks for the extra detail.

First some explanation, then a proposed solution!

Explanation

You're trying to override a configuration item provided by a different module, in this case Webform. That use case is not supported by Drupal core. (Okay, it is kinda sorta supported, by putting your override in the install profile, but that's not always feasible or desirable.)

The reason this doesn't work in Configuration Synchronizer is that altering extension-provided configuration in this way is explicitly disallowed in Drupal core. Regularly you'll get an error when you try to install a module that provides a configuration item that already exists on your site. For this reason, Features by default doesn't let you export a configuration item that's provided by a different module, though it does allow you to override that default.

Features also provides a workaround to the pre-existing configuration issue, allowing you to install modules that re-provide configuration items. We did this in Features because of the workflow issue that you often want to install a feature on the site where you generate it, and without this workaround that wouldn't be possible. But this isn't a solution for use on client sites. Features 8.x+ should not be installed except in a development context.

Solution

So what do you do? For a summary of the various options in contrib for altering extension-provided config, see what I put in #2960941: Provide an API for persistent configuration alters, including for extension-provided config a few years back--it still pretty much holds. Given you're using Configuration Synchronizer, you'll probably want to look at Config Actions, because there's already integration for it via Config Actions Provider. Config Actions has detailed documentation. An example from Drutopia Landing Page, a module I co-maintain, of how to write config actions is this config action that merges in settings for Exclude Node Title. Any subsequent changes to this file will be picked up by Config Actions Provider. For example, in this issue, we recently tweaked our changes to exclude node title, see this commit. Those changes will be made on new installs and also show up as available updates in Configuration Synchronizer.

Hope that helps!

Closing for now, please feel free top reopen with more details or questions.

No prob, I'll leave this open for awhile then, it would be valuable to hear what your team comes up with.

Override yaml files need to be created manually (there's no export feature GUI and/or drush)?
I don't think this manual approach would work for us, atm, since we are fully committed to using features. Maybe if we started with config actions, by now we would be fine. Also, template/override yaml format has a learning curve, I know I struggled with it in my simple use cases.

Our issue is that even if config-distro-update runs, and is in sync with active config, changes are not applied. I still need to run feature revert to apply those changes. This may be caused by features conflicting with config-distro-update. And I feel like we are past the point to remove features from the project. So, we will stick to it for now.

Override yaml files need to be created manually (there's no export feature GUI and/or drush)?

ATM, correct. And yes, it's a cumbersome process to have to write the overrides manually. That said, using Config Actions in this way is basically compatible with Features--we use both in the Drutopia features set.

Our issue is that even if config-distro-update runs, and is in sync with active config, changes are not applied.

Yes.

One potential solution would be to write an integration module between Features and Configuration Provider (e.g., features_config_provider) to cover your use case. See the Configuration Provider project page for developer tips. Basically:

• Provide a custom configuration provider plugin modelled on one of the existing ones, probably ConfigProviderInstall.
• In your provider plugin, iterate through Features modules (using the features.manager service, call FeaturesManagreInterface::getFeaturesModules()) and swap in their version of configuration items for the originals. This would work a lot like the existing support for overrides from profile storages.

You could do this in one of two ways:

1. Add your config provider plugin, giving it a relatively high weight, and just do the features overriding.
2. Implement hook_config_provider_config_provider_info_alter() ans swap in your plugin for an existing one (probably ConfigProviderInstall).

There's some potentially relevant work going on in Configuration Split per #3229247: Add service for creating config patches that can be saved and applied to the config again or Configuration Merge per #3229277: Adopt ConfigPatch and ConfigPatchMerge from Config Split. It's not there yet but, with additional work, could potentially be the basis of a better option for both generating and applying config "patches".