ConfigEntityInterface::isInstallable() returning FALSE can break config depndency resolution

Created on 14 January 2017, over 8 years ago

Updated 5 September 2025, about 18 hours ago

Problem/Motivation

If config entity B has a dependency on config entity A then ConfigInstaller will make sure to try to install A before B. If A, however, returns FALSE in its isInstallable() implementation - for whichever reason - ConfigInstaller still goes ahead and tries to install B. That will then eventually fail at some point (otherwise it wouldn't be a dependency), but ConfigInstaller should not even try to install a config entity of which it knows that its dependencies are not met.

This was found in #2840024: Entity browser entities with a Views widget or selection plugin should have a dependency on the respective View → where entity browser config entities are getting a proper dependencies on the views that they reference in their configuration. Since views are the only config entity in core that implement isInstallable() you need a config entity which depends on a view to reproduce this. Page Manager comes to mind, but I did not try this. Even then Views is kind of a bad example, because in order to reproduce this you need to create a situation where there is no views data for the base table of the view you are creating. Since Views adds a dependency of the provider of the base table information you need some manual hackery to achieve this. In #2840024: Entity browser entities with a Views widget or selection plugin should have a dependency on the respective View → this came up in a kernel test, as kernel tests do not enable dependencies of modules automatically. (And apparently the ConfigInstaller validation of installed modules is broken in kernel test, I realize now that I've written this ?!)

In any case we must assume that contrib modules to crazier things in their isInstallable() so we should be safe.

Proposed resolution

If a config entity is found to be not installable in ConfigInstaller find out if there are any config entities that are to be installed that depend on this one and - if so - throw an error instead of silently ignoring this.

Remaining tasks

User interface changes

None.

API changes

Data model changes

🐛 Bug report

Status

Postponed: needs info

Version

11.0 🔥

Component

configuration system

Created by

🇩🇪Germany tstoeckler Essen, Germany

Live updates comments and jobs are added and updated live.

stale-issue-cleanup
To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Incomplete comments

Comments & Activities

Not all content is available!

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

Comment about 18 hours ago →
🇺🇸United States smustgrave
Thank you for reporting this problem. We rely on issue reports like this one to resolve bugs and improve Drupal core.

Since there has been no activity here for over 8 years we are asking if this problem persists on a currently supported version of Drupal. To help, add a comment explaining if the problem still occurs or not. Any extra detail you can provide can help others who experienced this.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024