Every once in awhile, a new dependency gets added to a module, for example #3084983: Move all the code related to path aliases to a new (required) "path_alias" module added path_alias as a dependency to the path module.

When this happens, as in the above example, trying to import configuration which had been exported with a previous version of Drupal will result in:

[error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Unable to uninstall the <em class="placeholder">Path alias</em> module since the <em class="placeholder">Path</em> module is installed. in Drupal\Core\Config\ConfigImporter->validate() (line 755 of /var/www/html/core/lib/Drupal/Core/Config/ConfigImporter.php).

This is because, in the core.extension.yml generated before the new dependency was added, we have (in this example):

   path: 0

but not:

   path_alias: 0

So Drupal tries to enable path but disable path_alias; which fails. Thus, configuration which was fully acceptable with a previous version of Drupal (before the new dependency) is now corrupted (unusable) and needs to be regenerated with "drush config-export" to be valid again.

Upon enabling modules based on a core.extension.yml file, could we compute the dependencies automatically so that whether or not we have "path_alias: 0" in core.extension.yml, we would enable it? The code to do so already exists in ModuleInstaller::install.

Comments

alberto56 created an issue. See original summary.

lesleyfernandes’s picture

lesleyfernandes CreditAttribution: lesleyfernandes commented

I faced the same problem here while updating configs from old projects after updating the core to the 8.8.1 version.

gena.io’s picture

gena.io CreditAttribution: gena.io commented

@lesleyfernandes Did you solve this issue? And, if yes, how? Thanks

jelhan’s picture

jelhan CreditAttribution: jelhan commented

@lesleyfernandes Did you solve this issue? And, if yes, how? Thanks

I've resolved the issue by manually editing the core.extension.yml file and adding the line for the missing module. In my case path_auto: 0 was needed as in the example given above.

kevgrob’s picture

kevgrob CreditAttribution: kevgrob commented

In my case I had to add both pathauto: 0 and path_alias: 0

Mingsong’s picture

Mingsong
Location 🇦🇺
CreditAttribution: Mingsong commented

One solution with Config Ignore mdoule is to exclude the core.extension.yml from importing. That will remain the path_alias module enabled and the configuration import process won't try to disable the core module required.

If your site does need to import the core.extension.yml, in this case, you need to add the 'path_alias 0' into core.extension.yml before importing.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman as a volunteer commented

I've also run into this. The suggested workaround succeeded.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman as a volunteer commented
Issue tags: +CMI 2.0 candidate
alberto56’s picture

alberto56 CreditAttribution: alberto56 at Dcycle commented

Related: #3110362: If an update hook modifies configuration, then old configuration is imported, the changes made by the update hook are forever lost.

flyke’s picture

flyke CreditAttribution: flyke commented

I had this problem when deploying my git commited update from drupal 8.7.11 to 8.8.2.
What solved it for me was ssh to the server, run drush cr and then re-try the deployment

malek53923’s picture

malek53923 CreditAttribution: malek53923 as a volunteer and commented
Assigned: Unassigned » malek53923

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.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.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.

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.

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.