Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
The recommended use of Config Distro (which invokes Configuration Synchronizer) is described thusly:
Config Distro is designed to be installed and used at the base of a site's configuration management workflow--that is, the environment where extension updates are made.
Say you have a dev > test > prod workflow, where code updates are done in the dev environment and staged to test and prod. Config Distro would be installed and used on dev, since that's where extension updates are done.
Which matches how we handle configuration. It's always done on local first, committed, and then deployed to test and live:
If you're using Config Distro and also staging configuration updates, you'll want to run your distro updates first and then stage them to other environments.
This all sounds great— except for the next step in our workflow. For many sites, we frequently sync the live database down to local to be developing against real-world conditions. This means the `config_sync_snapshot_extension` which powers Config Distro will be, well, out of sync.
More than that, the live site is the one source of truth, and we like to reserve the right to trash any and all local environments. So excluding the `config_sync_snapshot_extension` from the sync down doesn't feel like a good solution either.
Proposed resolution
Switch to storing configuration snapshots as exportable simple configuration.
- Add a new class
SimpleConfigStoragethat implementsStorageInterface. The new class can be modelled onDrupal\config_provider\InMemoryStorage. - Switch
config_sync.snapshot_storageservice to useSimpleConfigStorageinstead ofDrupal\Core\Config\DatabaseStorage. - In an update, migrate snapshot data from old database table to new simple configuration and delete table.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | config_sync-snapshot-config-2981701-6.patch | 11.48 KB | nedjo |
Comments
Comment #2
nedjoBecause
config_sync_snapshot_extensionis owned by Configuration Synchronizer, this issue probably belongs in that module's queue. I'll leave it here for the moment and will try to return to this.Comment #3
nedjoMoving to Configuration Synchronizer.
These are good questions.
The snapshot answers the question: for the current environment, what was the state of the extension-provided configuration when either (a) the extension that provides it was originally installed or (b) the most recently config distro synchronization was run for the extension that provides it?
This indeed raises issues when dealing with different environments.
Say we have two environments, dev and live.
The recommended model is to merge in extension provided updates on dev and then stage them to live. When we do so, live's snapshot will now be out of date. We need to refresh it. But to what state? Ideally, to the state that was just merged in. That is known with certainty only on the source environment (in this case, dev). So it seem like we need to stage at least some snapshot data as part of or after configuration synchronization.
What about db synchronization? When we pull the db from live to dev, we are also pulling config--replacing the config on dev with the version on live. So after pulling the db from live, the snapshot on dev should reflect the last imported state on live. This should already be working, since the snapshot will have been pulled as part of the db.
The config staging considerations seem to indicate we should be storing the snapshot as config, not merely in the db, so that it too is staged.
Updating the summary accordingly.
Comment #4
nedjoComment #5
nedjoComment #6
nedjoHere's a patch that implements the approach outlined in the issue summary. Needs testing.
Comment #7
nedjoIn #6 I used simple configuration to store a config snapshot. But on consideration we might be better off with a config entity type. As well as other advantages, that would facilitate one snapshot per extension.
Comment #8
nedjoOne snapshot per extension means we can reliably answer the question: what config has been removed from this extension since the previous snapshot point?
I've written and posted a new module for this purpose, Config Snapshot.
The work remaining is to refactor Configuration Synchronizer - and, potentially, other modules in the mix - to use one snapshot per extension. This looks to involve considerable refactoring.
Comment #12
nedjoThis is now working.
The work includes an update that migrates existing snapshots to the new config entity.
Before updating, it's necessary to install the Configuration Snapshot module.