Problem/Motivation

The excluded modules feature just removes all config that depends directly or indirectly on the excluded modules from the exported config. This works great for the intended use-case of excluding development modules such as devel. Because devel doesn't add third party settings to all of the config.
But conceptually the operation should be equivalent to uninstalling the modules, exporting the config and then installing the modules again and configuring the modules the same way again.

Steps to reproduce

Install Umami
$settings['config_exclude_modules'] = ['menu_ui'];
Export config
Discover all of the recipe content type is missing.
(This is because node.type.recipe depends on menu_ui because it has third_party_settings for it.)

With this issue the third_party_settings for menu_ui would be removed from node.type.recipe on export and added again on import.

Proposed resolution

Removing the things is easy, adding it back is hard without predictable sorting. (We can maybe sort by the active config)
(see an experiment in contrib: #3170204: Add option to remove modules as if they were uninstalled)

Remaining tasks

tbd,

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

Excluded modules change the configuration as if they had been uninstalled instead of removing all dependent config.

Comments

bircher created an issue. See original summary.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ressa’s picture

Reproduce with Views UI
$settings['config_exclude_modules'] = ['views_ui'];
Check "Administer views" for "Content Editor"
Export config
Discover that the "Content Editor" role was removed on next config:import:

 [notice] Synchronized extensions: uninstall views_ui.
 [notice] Synchronized configuration: delete system.action.user_add_role_action.content_editor.
 [notice] Synchronized configuration: delete system.action.user_remove_role_action.content_editor.
 [notice] Synchronized configuration: delete user.role.content_editor.
benjifisher’s picture

According to #2571235-245: [regression] Roles should depend on objects that are building the granted permissions,

If a module provides permissions that are in use by any user role, and that module is config-excluded in $settings['config_exclude_modules'], then any user roles with those permissions checked will also be excluded from config export/import.

This affects Drupal 9.3.0, the first full release including #2571235.

johnpitcairn’s picture

Yes, and any previously exported config for the role will be deleted. This could bite hard when upgrading from 9.2.x.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

holo96’s picture

StatusFileSize
new1.69 KB

I guess we will need tests for this
Maybe even to update existing ones

But let's first do maual testing.

PS. Roles are also updated at least in drupal 10 where I tested this.

holo96’s picture

Status: Active » Needs review

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

holo96’s picture

Version: 11.x-dev » 10.1.x-dev
bircher’s picture

Status: Needs review » Needs work

The patch in 8 is a good start, but it is far from complete. It currently does the removing only. It also needs to put the removed config back in a "patch" way, otherwise on an import the removed things will not be added again. I think it would be best to start with a test here.

The test would have a config which changes when a module is excluded. (such as a role having the permission removed)
The test should assert that the permission is not present in the exported config, but when importing the config again the permission should be set again. At the very least. There are other cases we should test too but this would be a good start.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

seanr’s picture

I can confirm patch in #8 only partially fixes it. It's a damned good thing I watch those config diffs like a hawk. 🤣 FWIW, I'm now using https://www.drupal.org/project/config_ignore and I recommend that anyway as it's targeted to specific configs rather than the whole module.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.