Default configuration entities could depend on a module that is not installed.
Implement some additional pre module install configuration validation. We have two different situations to handle:
Module provides configuration with an unmet dependency
If a module provides configuration that has unmet dependencies and that module is being installed a
UnmetDependenciesExceptionwill be thrown. The module install forms will catch this exception and display an informative message to the user.
Module provides a configuration entity type where an already installed module provides a configuration entity of that type
If the configuration is being created during an install due to it being provided by an already installed module then this is logged to watchdog. This is because the module being installed does not contain any incorrect configuration so we should proceed with the install.
Steps to test
- Install minimal
- Uninstall the node module
Change the views.view.frontpage.yml (provided by node module) to have the following dependencies key:
This creates an unmet dependency
- Install node - this should work
- Install views - this should work. In HEAD, a broken frontpage view will be created, but with the patch, the frontpage view will not exist. (If you did not add the Book dependency to the view, it would exist at this point.)
- Uninstall views and node
- Install views
- Install node. In HEAD, this will succeed and again install the broken view. With the patch, this should fail and an error message appear indicating that a dependency is missing for the view.
User interface changes
Message to user about missing dependencies for configuration.
- Change ConfigInstaller::findPreExistingConfiguration() to be the more generic ConfigInstaller::checkConfigurationToInstall()
- Add a new install step that installs an install profile (
install_install_profile). This is so that themes can installed before the profile so that the profile can provide configuration that depends in the theme.
Original report by @catch
Found by alexpott on https://drupal.org/node/2003966#comment-7866263
- Module A provides some default configuration, to be enabled when module B is enabled.
- The default configuration references a plugin owned by module C
- Module C is not enabled when either module A or module B are
- The default configuration is installed, and is immediately broken - in Views it'd be a broken handler, some other systems can't handle it at all.
We should probably not install the configuration, if it's going to be invalid as soon as it's installed. That'd make this one a counterpart to- certainly the validation in there is going to be necessary for whatever happens here.
A couple of options then:
- skip the configuration install silently. This brings up the question of whether that configuration will ever get installed (i.e. if module C is enabled we're not going to look for configuration files in module A just in case they have a plugin owned by module C.
- prompt the person enabling the module to see if they'd also like to enable module C at the same time, then they can answer yes or know and we forget about this config file after that.
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,411 pass(es).|
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,401 pass(es).|
|PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,380 pass(es).|