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.(Submitted by @danepowell and migrated from GitHub: https://github.com/acquia/lightning/issues/265)
Right now there are two main methods of configuration management (CM) for installed sites. One is to use the core CM system--placing config into /config/default and importing it on deploys. The other is to use Features--packaging the config into individual modules and importing Features individually or in bulk (features-revert-all) on deploys. For various reasons, Features is currently the only practical option for certain sites (the core CM system isn't very versatile and doesn't support multisite well, etc...)
Managing configuration with a Lightning-based install is currently a challenge. The problem is that Lightning provides all of its config as Features, and Features by default does not allow the same configuration to be exported twice (even in uninstalled modules). This means that in order to maintain an override to Lightning-provided configuration right now, you either have to use the core config system (untenable for some sites) or force Features to allow conflicts. Allowing conflicts isn't ideal, as it opens the door for silly mistakes later on (new developers exporting the same config yet again in a different feature), and I've heard reports that it doesn't behave as expected (conflicting config doesn't actually get imported).
The easiest solution would be to remove the *.features.yml files from Lightning, i.e. allow the configuration to be provided as normal Drupal modules rather than as Features. I don't think this would have any negative side effects, since Lightning already provides config updates via update hooks--it doesn't assume you're going to import (revert) features. And indeed it shouldn't... the paradigm in D8 seems to be that once a module provides a default configuration, that configuration is "owned" by the site and no longer by the module.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | lightning-2846724-5.patch | 6.49 KB | Dane Powell |
Comments
Comment #2
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedThank you :)
Comment #3
balsamaThanks for getting this dialog started, Dane.
I think the original idea behind using features was so that users could get a visual representation of what had changed. And, in theory, users could revert a particular piece of functionality if they needed to. There might have been other reasons (maybe we just liked that Features helped us automatically gather all the config related to a feature) but I'm not sure.
I totally agree with this:
And, as you point out, we don't attempt to update our config via features since the users "own" that config.
So, as I see it, the pros and cons of removing the *.features.yml files from lightning modules:
Pros:
Cons:
I'd like to get some feedback from the features maintainers and other users to see if they have strong opinions/suggestions either way. I'm definitely not opposed to just removing the *.features.yml files, but want to make sure there is a consensus.
Comment #4
balsamaTangentially related: #2848180: Rename "Allow conflicts" checkbox and give it a better description
Comment #5
Dane Powell CreditAttribution: Dane Powell at Acquia commentedConfig Update provides a UI to report on configuration differences, and now also allows you to revert configuration entirely without Features: #2822721: Add config-revert and config-revert-all drush commands
Admittedly, I haven't tried either of these so I don't know if they are quite as streamlined as Features, but it's at least possible.
The only real downside I see might be for the Lightning maintainers, I suppose it would be a little more work to export configuration in the future (since you'd need to manually strip the UUID and site hash).
I wonder if Features could use a new configuration option to generate unFeatures... i.e. plain old non-Feature Drupal modules. Basically decoupling its export / import / management functions.
For anyone wanting to de-featurize Lightning in the meantime, here's a patch.
Comment #6
mpotter CreditAttribution: mpotter at Phase2 commentedI think maybe those Lightning Features were generated with an older version of Features. There is no need to have the details of the specific config specified in the "required" section of the feature.yml file. Just a simple "required: true" is all that is needed.
Features doesn't need any option for generating "unFeatures". The checkbox already in Features (currently called "Allow conflicts") is designed to turn off the detection of config in modules to allow you to export anything to any feature. I don't really understand why simply checking this box is a burden since that's what it was designed for. It's purpose is to prevent people who don't know what they are doing from accidentally exporting the same config to multiple locations. This is because in Drupal Core, if you don't have Features enabled (like on Production) you wouldn't be able to enable multiple modules that contain duplicate config.
For users who understand what they are doing, you simply check that box and then put the config wherever you want.
I think there is an issue in the Features queue to rename this option "Show all config" or something like that since there isn't any concept of "Conflicts" in D8 really.
If there is a bug with the Allow Conflicts checkbox, then please post details on reproducing in the Features issue queue. I don't see this as a Lightning issue.
I agree that a better system to support configuration "overrides" is needed and I'm working on a module that will hopefully solve this problem soon. But the solution is not to have duplicate config in both a Lightning module and a site-specific module. That will cause problems for the core CM system and requires you to have Features module enabled on production to allow pre-existing config to be imported, or requires a complex deployment strategy. Features is not designed to provide an "override" mechanism in D8 so trying to use it for that purpose will likely cause problems.
Comment #7
saltednutFWIW, we (Demo Framework team) use Configuration Rewrite to 'override' config without actually doing a core version of an override, which happens on every process and is basically a 'live' override.
This does require the module to set up the config/rewrite directory but that's pretty much it. No 'revert' support yet but we do have a Features issue in our queue.
Comment #8
balsamaOne thing seems clear: the implementation here is causing more pain than anything. I'm going to remove the features files altogether according to dane's patch.
Comment #10
balsamaComment #12
akprasad303 CreditAttribution: akprasad303 as a volunteer commented