Comparing active storage to install storage is problematic, install storage may change anytime

Is the version number (8.1.x) correct ? If this is a beta-upgrade blocker, I assume we need this before 8.0.x is released

+++ b/core/lib/Drupal/Core/Config/ConfigInstaller.php
@@ -203,9 +203,16 @@ protected function createConfiguration($collection, array $config_to_install) {
+        // Create a copy of the original configuration for later reference.
+        if ($collection == StorageInterface::DEFAULT_COLLECTION) {
+          $config_copy = new Config($name, $this->getActiveStorages(StorageInterface::ORIGINAL_COPY_COLLECTION), $this->eventDispatcher, $this->typedConfig);
...
+        if (isset($config_copy)) {
+          $config_copy->setData($data[$name])->save();
+        }

+1 on making a copy of installed config

+++ b/core/lib/Drupal/Core/Config/FileStorage.php
@@ -231,7 +231,7 @@ public function deleteAll($prefix = '') {
-      if (!(new \FilesystemIterator($this->getCollectionDirectory()))->valid()) {
+      if (file_exists($this->getCollectionDirectory()) && !(new \FilesystemIterator($this->getCollectionDirectory()))->valid()) {

Nice catch for UnexpectedValueException
so bug

Discussed with @Gábor Hojtsy, @xjm, @mtift on a recent CMI call.

This issue introduces a requirement to know how default schema is changing over time. The current proposal stores a copy of the configuration during installation. It stores it in configuration using a special configuration collection. It does this regardless of whether your site is currently using config translation because as some point in the future you might enable it and at that point we need to know the state of the configuration at the point you did the install to know how to possibly translate it. I don't particularly like the current solution because it duplicates everything in active configuration, the install time copy is not really active configuration and it will pollute configuration synchronisation with it's duplicates.

The alternate solutions discussed were:

To never change default configuration once we reach 8.0.0.

This might work for core but it is unlikely to work for contrib which moves at a greater pace and has less controls.

Store previous configuration defaults in the extension

The idea is to store previous versions in the extension's configuration directories. If an extension's default configuration changes then a copy of the old configuration is made. The current folder structure is:

 |-config
 |---install
 |---optional
 |---schema

As updates are made we add the special update directory. Say something changes in the install directory...

 |-config
 |---install
 |---optional
 |---schema
 |---update
 |-----8000

We add a new config storage directory of update and a sub directory of 8000. When this extension was installed before the lack of any configuration update directories in the install or optional directories meant that we stored (in configuration - probably core.extension) that the module was on config version 8000. Now if the extension is stored on a new site we store a config version of 8001.

If we then update something in the optional directory...

 |-config
 |---install
 |---optional
 |---schema
 |---update
 |-----8000
 |-----8001

We a new sub directory of 8001. Optional and mandatory configuration can share an update folder because clashes are impossible. Now if the extension is stored on a new site we store a config version of 8002.

Then if the config translation module is installed it can know the configuration version used at install time and find the original configuration in the extension's update directory.

This change (whichever way it goes) will have upgrade path implications for currently live sites.

This issue is fascinating. So I have this contrib module https://www.drupal.org/project/config_update -- it provides a report that you can run (UI or Drush) that shows differences between the config that is config/install and/or config/optional vs. the active config. It separates out modified, added, and removed config.

Immediately after installing with Standard install, you will see that the report is not empty, because modules/profiles modify config by doing things in code instead of in config files.

So ... I guess my point is: even if the config schema or contents of config/install do not change due to an update, the installed config is not equal to what is in the config files.

Added to config management usability meta #2642404: [meta] Usability improvements to configuration management post 8.0

Some of the use cases for comparing configuration to a previous state require information about the providing extension type and name. This is the case when comparing an extension's currently provided configuration to a prior state to determine available updates. In contrib this need is addressed through the Configuration Snapshot module.

To cover that use case, several changes would be needed, including:

• Snapshots should include extension-provided configuration from non-default collections.
• Code constant naming should not refer to an "original" copy, since the snapshot might have been refreshed via a later configuration update.
• Configuration should be snapshotted into separate collections, one per extension type/name combination.

How does this proposed change relate to the existing _core.default_config_hash value that's set for imported configuration? having a full copy of the configuration would seem to make the hash potentially obsolete.

Further to #36:

For the use case of comparing an extension's currently provided configuration to a prior state to determine available updates, each snapshotted item should include data on its collection. This means the proposed approach of saving all snapshots to a particular collection in the active configuration storage, or even one collection per extension/extension type combination, won't be valid, since that would support saving only the configuration item, not its original collection. A closer model is the core config.storage.snapshot service and accompanying config_snapshot table, which has a field for collection. However, that approach produces data that is not exportable. Another possible model is the Configuration Snapshot module.

Updating tag.