Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.This initial "bug" report is five years too late. It is now a major feature request.
Config collections are an undocumented subsystem that was introduced after this module was written. It would be ideal if we used them, as they should allow for full schema support. Schema validation is a nicety that only matters to programmers, so far as I can tell, so it is not an essential feature.
Problems that need to be overcome in order to support this initiative are:
- The ability to discover what config has been overridden and stored.
- The ability to know which elements of a config object are being overridden, since we support partial overrides.
- The ability to reliably discover configuration objects and their related forms without using a config_translation.yml style hack.
- The ability to integrate existing or replacement functionality for a Domain Config UI as shown in https://github.com/agentrickard/domain/pull/434
- An upgrade path for existing users.
- Working tests
I will not be working on this without dedicated, paid support, but I am happy to review code. Pull requests are preferred for work of this complexity.
Original post:
Using config_inspector module to validate config schemas we get "No schema" for every domain config override.
According to Drupal's documentation it is recommended to have schemas for configuration objects, see https://www.drupal.org/docs/8/api/configuration-api/configuration-schema...
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | no-schema-domain-config-overrides-3060758-1.patch | 1.85 KB | piggito |
Issue fork domain-3060758
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
piggito commentedThe attached patch fixes schema detection for "domain.config.." but I couldn't fix it for the case when we add language "domain.confib...".
Language config override gets tricky cause languages are also config objects which depend in typed config processing so we don't have access to language manager at this point.
IMO we should be using config collection for overrides as core does but mb I'm missing something so I would like maintainer's opinion on this.
Comment #3
agentrickardI am _not_ rewriting the config loader. This is not a bug.
Config collections are entirely undocumented, so please feel free to rewrite the entire system as a patch, so long as it accounts for the work in https://github.com/agentrickard/domain/pull/434
This is not a bug, it is bad API design from core -- and even worse support for an issue I raised in 2014.
Comment #4
agentrickardI do know that @andypost was working on this at one time.
Comment #5
agentrickardComment #6
mably commentedWe should keep this on our todo list.
Could be for a 3.x release.
Comment #8
mably commentedAll tests are green. Everything seems to work fine. Please review.
Any feedback welcome.
Note that we are now using the default Drupal Configuration Translation mechanism, so only the translatable fields are now available for translation when using the Drupal UI.
No migration path is currently provided.
Comment #9
mably commented.
Comment #11
mably commentedReleased in 3.0.0-alpha1.