Still exporting config saved in a features custom module

Created on 26 May 2020, over 4 years ago
Updated 15 July 2024, 4 months ago

Thank you for the great and straightforward way of handling config deviations from the base install profile! This may be a bug, or just an indication that I don't really know what I'm doing, so please bear with me...

I have an install profile with a blog content type, which includes the entity, the entity form display, and several entity view displays saved as config with that profile. In one site that uses that install profile, I have made changes to the form and the displays (i.e., removed a field, changed another, added still more). As expected, when I run `drush cex` I get those modifications output to the appropriate site config/sync directory (as set in settings.php). But when I package up those modified config files as a discrete Features module and then export, there seems to be no impact at all. I would have expected that they would not have been exported given the module description:

Installing this module and subsequently exporting configuration will leave only those configuration files in your export directory that have been added or modified relative to the shipped configuration of modules and installation profiles.

If that's not something that's within the scope of this module, let me know.

πŸ› Bug report
Status

Closed: works as designed

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States beunerd Providence, Rhode Island

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany tstoeckler Essen, Germany

    Hi there! Thanks for trying out this module and apologies for not responding for so long.

    If I understand your situation correctly, you have configuration in a custom features module and then you have the same configuration file (albeit with different configuration) in an installation profile. If that is the case it is absolutely expected for the profile to "win" and so effectively for your features module to be ignored at least with respect to those configuration files. Drupal core is not very lenient with this sort of "duplicate" configuration, regardless of Config Overlay. For example, if you have two different modules that provide a node.type.article configuration in their config/install directory, Drupal will refuse to install those two modules. The only exception are install profiles, which are explicitly allowed to override module-shipped configuration, but never the other way around. So in your case you could move the configuration that is now in the profile into a different feature module and then only have either one of them enabled on any given site? If there is some overlap in configuration they could both depend on a "base feature" module to decrease the duplication. That should all work fine with Config Overlay.

    Alternatively, you could have modules put their configuration in config/optional but then it really depends on which module gets installed first (and any subsequent modules which provide the same config will be ignored), so for an actual features module this is not ideal either.

    I hope this makes sense. I will mark this as "Postponed (maintainer needs more info)" so you can confirm that you are able to resolve the issue and there is in fact no issue to address here. If you do not respond I may just close the issue in the future.

  • Status changed to Closed: works as designed 4 months ago
  • πŸ‡©πŸ‡ͺGermany tstoeckler Essen, Germany

    Closing this for now as there is nothing actionable here, as far as I can tell. Feel free to re-open if there is in fact a bug or problem that we can fix.

Production build 0.71.5 2024