Default config hash is not generated for imported configuration (config_provider)

Thanks, this looks like a good start.

A config hash should be generated only for configuration that is provided by an extension, and, likely, only when the configuration is being prepped for writing as opposed to comparison.

So we may need some new methods in ConfigNormalizerBase parallel to existing ones. By calling both new methods, we ensure we're applying the normalization only as needed. Here are some quick and untested suggestions.

A new method ::isProvideModeContext() parallel to ::isDefaultModeContext():

  protected function isProvideModeContext(array $context) {
    return !empty($context['normalization_mode']) && ($context['normalization_mode'] === NormalizedReadOnlyStorageInterface::NORMALIZATION_MODE_PROVIDE);
  }

And a new method ::isProviderStorageContext() parallel to ::isActiveStorageContext(). Here, I guess, we test for the service ID of the Configuration Provider storage:

  protected function isProviderStorageContext(array $context) {
    if (
      !empty($context['reference_storage_service']) &&
      !empty($context['reference_storage_service']->_serviceId) &&
      ($context['reference_storage_service']->_serviceId === 'config_provider.storage')
    ) {
      return TRUE;
    }

    return FALSE;
  }

Or, maybe better, we introduce a helper method:

  protected function isStorageServiceContext(array $context, $service_id) {
    if (
      !empty($context['reference_storage_service']) &&
      !empty($context['reference_storage_service']->_serviceId) &&
      ($context['reference_storage_service']->_serviceId === $service_id)
    ) {
      return TRUE;
    }

    return FALSE;
  }

and use that for both the new method and the existing one:

  protected function isStorageProviderContext(array $context) {
    return $this->isStorageServiceContext($context, 'config_provider.storage');
  }

Hmm. The approach I've suggested might not be right. Because config from Configuration Provider may already have been altered. For example, the module Config Actions Provider applies alters via Config Actions. We need to ensure we're generating the hash for the config in its pristine state as read from the config/install or config/optional directory. So, possibly, we should be doing this in Configuration Provider instead? As a new method in ConfigProviderBase that we call in both ConfigProviderInstall and ConfigProviderOptional?

I haven't had a chance yet to look again at this, will update when I do. Meantime, moving to Configuration Provider issue queue.

Thanks for working on this!

::addConfigToCreate() is invoked at extension install time. Core already covers that case for adding a config hash to config from config/install and config/optional.

Where we need to work in this issue is ::addInstallableConfig(), which is what's called to provide config to config_sync.

Looks good!

I haven't tested but please feel free to apply once you're confident it's working.

One note:

+++ b/src/Plugin/ConfigProviderBase.php
@@ -292,4 +293,24 @@ abstract class ConfigProviderBase extends PluginBase implements ConfigProviderIn
+    if (empty($data['uuid']) && empty($data['_core']['default_config_hash'])) {

I believe in some cases a uuid is valid on extension-provided config, so perhaps we should be testing only for the second value.

While testing my patch, I saw that couple of even core modules also had no default_config_hash property, although they have the configs in config/install folder.

Yes. the default_config_hash is generated by core when extension-provided config is installed, so it should not be present in the config/install folder files.

But maybe we also need to perform the checks like here is the patch

Hmm, good question. It's presumably true that we have a situation similar to that noted in #2628004: Create an upgrade path to determine if default_config_hash should be added (2625258): on existing sites running our module there may be config we installed that lacks a hash. I'd say:

• Let's test to see whether we get the config hash when we run configuration update after applying this patch. That is: does the hash show up as importable? When we run an import, does our previously-installed config end up with the hash? If so, I suppose we're good.
• If that doesn't work, let's open a new follow-up issue, so we can fix this one right away.