Currently, config overrides offer (as far as I can tell) no introspection whatsoever. If you are not the config factory service, it's impossible to reliably determine all config overrides that are in effect. But for contrib modules that want to work around Core issues like #2744057: Inconsistencies when updating overridden config entities and #2408549: Display status message on configuration forms when there are overridden values until they are fixed, this information would be crucial in some cases, and in others at least make things a lot easier.
My simple suggestion: just make \Drupal\Core\Config\ConfigFactory::loadOverrides() a public method (and, of course, also adding it to the interface). Since, obviously, nothing can be using this method from the outside currently, it doesn't seem like this should have any unforeseen impact.
Well, at least as far as making the method public is concerned. I guess adding the method to the interface could break other implementations, so maybe this could be a follow-up for 8.4. But it would be really great if we could still get this change in for 8.3. These problems with config overrides really cause some hard-to-resolve bugs in contrib modules, and this would be a simple, yet effective way of making it easier to deal with them.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 2860819-2--make_loadOverrides_public_and_add_to_interface.patch | 1.72 KB | drunken monkey |
| #2 | 2860819-2--make_loadOverrides_public.patch | 694 bytes | drunken monkey |
Comments
Comment #2
drunken monkeyTrivial patches attached.
Comment #3
drunken monkeyI still support this feature request, but since looking for tagged services manually is a not-too-hard workaround, it's probably not quite that urgent.
Comment #6
borisson_I think we can close this issue now that #2923004: Add method to check if any overrides are applied to \Drupal\Core\Config\Config is in.
Comment #7
drunken monkeyNot sure. While it's true that #2923004: Add method to check if any overrides are applied to \Drupal\Core\Config\Config improved the situation at least somewhat, having
loadOverrides()public would still be better for the Search API, as we still need to manually get the actual override values (see #2936630-2: Use new Config::hasOverrides()). Having that returned right away from Core would make things a bit simpler still.Since there doesn't seem much interest in this issue anyways, it probably won't happen either way, but I'd say we let it open for now.
Comment #17
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
If still a valid feature request it will need some tweaks.
Any new functions or properties should be typehinted
Will need to show test coverage
Will need a change record to announce this new public function.
Did not test btw