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
I have a Features module "ps_core" where I'd like to provide overrides for core's default date formats. This works fine for "medium" but not for "short" or "long". This is because the two test modules that Features ships with "test_feature" and "test_mybundle_core" provide overrides for these formats. They are taking precedence over my module's overrides!
Steps to reproduce
Create a features module that is alphabetically higher than test_feature (so it gets loaded first) and include an override for a core's core.date_format.short.yml. Enable the feature module.
Attempt to revert to short date format and observe it doesn't appear to work.
Proposed resolution
Not really sure! I was originally thinking - oh - let's just exclude modules that are in the "Test" package from being scanned, but of course that would prevent the test modules from working!
I'm going to write a patch that just removes the test modules from my project, but that's obviously not a real solution for everyone.
Comments
Comment #2
nedjoProviding overrides of extension-provided config is not supported by Features except in the limited use case of install profiles; see #2825834-15: Prevent PreExistingConfigurationException by prioritizing features config and other comments in that issue.
The rest of this issue may be a duplicate of #2975820: Features scans uninstalled extensions for config?
[Edited to fix incorrect issue link.]
Comment #3
bkosborneOh interesting. We have a module that overrides lots of config that's provided by other modules (e.g. webform.settings.yml, pathauto.settings.yml). This has worked for us for years. Sounds like we're taking advantage of something that happens to work now but is not a proper supported feature of Features. Though, this module does live within our install profile folder, maybe that's work it works.
Comment #4
nedjoYeah, if you have Features installed on your live site(s) then likely that's what's sorta kinda making this work for you.
The exception in Drupal core that allows re-providing config that's already provided by a different extension is only for the install profile itself. Documentation on this feature isn't easy to find, but see
ConfigInstaller::getProfileStorages().For more on options for altering, see #3220207-5: Some config changes not being seen and other comments in that issue and (for good measure!) #3224762-2: Any way to exclude specific role permissions from being exported/causing a "changed" status?. There's also a newly-posted module Install-time Config Override (dev release only).
My view is that the most promising work on config alters/overrides is going on within the 2.x branch of Configuration Split, see the notes on "quasi-patches" in this blog post. But AFAIK that is not (yet) ready for use outside the Configuration Split workflow.
Comment #5
bkosborneThanks for the wealth of information!