Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
#2140511: Configuration file name collisions silently ignored for default configuration prevented default configuration collisions but special-cased install profiles, meaning that a site's install profile may provide configuration items already provided by an installed module. Currently the standard profile provides two such items (system.cron and system.theme), both simple configuration items already provided by the system module.
However, it's unclear that the special casing for install profiles will provide significant benefit. In Drupal 7, most complex install profiles divide default configuration among multiple modules so that configuration bundles can be selectively enabled. Work has begun to replicate this functionality in Drupal 8. There are no strong indications that distributions will start to put all their configuration into an install profile.
So it appears the considerable complexity added by special casing install profiles may not be justified. Distributions likely will not benefit from it, and will instead have to provide their own solution to achieve the same end.
Proposed resolution
Remove the special casing. In the standard profile, make required customizations to existing configuration in hook_install().
Comments
Comment #1
nedjoComment #2
mpotter CreditAttribution: mpotter commentedI'd like to see this issue get more attention also. There needs to be a general, clean, documented method for allowing a module to be installed that contains conflicting configuration, even if it means the configuration from that module is ignored in favor of the existing site config. Causing an exception and failing the module install is a poor solution.
I can currently install a module with no config, then later add a config file to the module and yet the module remains enabled. I can then use code or modules like config_update to load that new config into the active store. So what was the point of preventing the module from being installed with the config in the first place?
What if I create a View and then I want to put that view into my module? I cannot install the module because the view already exists in the active store. I have to export the view, then *delete* the view, then add the view config to my module and then enable it. Again, a mess of a workaround.
The exceptions made for install profiles seem like a kludge only designed to handle the case of the standard drupal install that needs to override some config. But this is not just an issue with install profiles. There are many use cases especially in development of modules where you need to install a module that just happens to have existing config in it.
I'm not even trying to debate the issue here of config overrides. I'd be happy if installing the module just ignored the module's config if it already exists, just as if the module was originally installed and then the site config was changed. The site config can still be the "master". But please let me still enable the module somehow!
Comment #3
pjcdawkins CreditAttribution: pjcdawkins commentedThis may be related
Comment #4
alexpott#3 is not related.
re #2 quite a few of the problems are resolved by optional configuration and #2461513: The ConfigInstaller should add a dependency on the extension used to install the configuration
So this is a complex issue. We have tension between modules providing functionality and configuration (expressions of that functionality) - a lot has moved to install profiles in core. But in my mind not enough has. For example, think views.view.frontpage does not belong in the node module. I think it should be in standard profile. However this does not help with contributed modules that a distribution uses.
As for a solution to the problem where a distribution wants to override configuration provided by a module the only solution I can think of is some override key in the install profile .info.yml file that has the module name and configuration name which would be checked by the config installer.
Comment #15
nedjoFrom the current documentation on proposed Composer project templates:
So adding "Distribution Modernization Initiative" tag.