#2080823: Create API to discover config entities' soft dependencies and use this to present a confirm form on module uninstall → added a method getDependentEntities() to \Drupal\Core\Config\Entity\ConfigDependencyManager. The documentation for this method simply says that it "gets dependencies". The implication is that it returns the list of forward dependencies for a given configuration entity. For instance, if I pass it a field instance config, I would expect it to return just the storage config as a dependency. If I pass the field storage config, I would expect it to usually return nothing.
However, the actual behavior seems to be to return the entire dependency tree, including reverse dependencies. In other words, if I pass it a field storage config, I get the field instance config and everything that depends on that config (for instance, views) all the way back up the dependency tree. This is because the method in turn calls createGraphConfigEntityDependencies(), which returns the reverse paths for the dependency graph.
This is problematic because Features relies on this method to return the dependencies for a given config ( #2533844: Use ConfigDependencyManager for determining config dependency → ), but since it's actually returning dependencies and dependent configs, dependencies are erroneously included, causing #2720167: Config dependency detection logic → .
At the least, the documentation for this method needs to be updated to clarify the intended behavior. If the method is behaving as intended, then Features is probably using it incorrectly and needs to find a new method of building dependencies trees. If the method is not behaving as intended, then it needs to be patched.
Needs work
11.0 🔥
configuration system
Enhances developer experience.
Primarily changes documentation, not code. For Drupal core issues, select the Documentation component instead of using this tag. In general, component selection is preferred over tag selection.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
What is the "needs work" here? Is it comment #21?
21.1 - doesn't this say "for example"? Not sure what this could change to, if there are suggestions I can make an update.
21.2 - I don't think you can pass "content" here, or you will get a blank array. That seems to me why it's being removed. It's the same behavior as if you passed "foobar". Maybe this should change to an enum at some point instead of a string? Not sure how that works for BC though.