Problem/Motivation
After doing a recent installation of Drupal 9.4.5, we came across the following problem and error message when browsing at:
Comment: Type Comment, Manage default display page: /admin/structure/comment/manage/comment/display
Config: core.entity_view_display.comment.comment.default
Error message displayed in logs at: /admin/reports/dblog
Type: system
Message Entity view display 'node.article.default': Component 'comment' was disabled because its settings depend on removed dependencies.
Severity: Warning
Tested with:
- Drupal core: 9.4.5 Standard installation profile
- PHP 7.4
Problem: Unfortunately, as a result, the Comment field is disabled when displaying Article Nodes (Hidden).
Steps to reproduce
So the steps to reproduce should be quite straight forward:
1 - Install a new site with the Standard profile.
2 - Browse to Comment/Comment manage display: /admin/structure/comment/manage/comment/display
3 - Check error logs: /admin/reports/dblog
Initial investigation
After doing an initial investigation, the error message would seem to come from the following piece of code:
https://git.drupalcode.org/project/drupal/-/blob/9.4.5/core/lib/Drupal/C...
// If there are unresolved deleted dependencies left, disable this
// component to avoid the removal of the entire display entity.
if ($this->getPluginRemovedDependencies($renderer->calculateDependencies(), $dependencies)) {
$this->removeComponent($name);
$arguments = [
'@display' => (string) $this->getEntityType()->getLabel(),
'@id' => $this->id(),
'@name' => $name,
];
$this->getLogger()->warning("@display '@id': Component '@name' was disabled because its settings depend on removed dependencies.", $arguments);
$changed = TRUE;
}
It would seem a lot of this code relates to issue: #2562107-77: EntityDisplayBase should react on removal of its components dependencies.
After doing some basic debugging, breaking at this point in code resulted in the following stack trace:
array:55 [▼
0 => array:7 [▼
"file" => "/web/core/lib/Drupal/Core/Config/ConfigManager.php""line" => 497
"function" => "onDependencyRemoval""class" => "Drupal\Core\Entity\EntityDisplayBase""object" => Drupal\Core\Entity\Entity\EntityViewDisplay {#2650 ▶}
"type" => "->""args" => array:1 [▶]
]
1 => array:7 [▼
"file" => "/web/core/lib/Drupal/Core/Config/ConfigManager.php""line" => 360
"function" => "callOnDependencyRemoval""class" => "Drupal\Core\Config\ConfigManager""object" => Drupal\Core\Config\ConfigManager {#857 ▶}
"type" => "->""args" => array:4 [▶]
]
2 => array:7 [▼
"file" => "/web/core/modules/user/src/Form/EntityPermissionsForm.php""line" => 88
"function" => "getConfigEntitiesToChangeOnDependencyRemoval""class" => "Drupal\Core\Config\ConfigManager""object" => Drupal\Core\Config\ConfigManager {#857 ▶}
"type" => "->""args" => array:2 [▶]
]
3 => array:7 [▼
"file" => "/web/core/modules/user/src/Form/EntityPermissionsForm.php""line" => 173
"function" => "permissionsByProvider""class" => "Drupal\user\Form\EntityPermissionsForm""object" => Drupal\user\Form\EntityPermissionsForm {#2057 ▶}
"type" => "->""args" => []
]
4 => array:5 [▼
"function" => "access""class" => "Drupal\user\Form\EntityPermissionsForm""object" => Drupal\user\Form\EntityPermissionsForm {#2057 ▶}
"type" => "->""args" => array:3 [▶]
...
Mostly, with this chain of calls:
[... Multiple calls before ...]
Drupal\user\Form\EntityPermissionsForm:permissionsByProvider
Drupal\Core\Config\ConfigManager:getConfigEntitiesToChangeOnDependencyRemoval
Drupal\Core\Config\ConfigManager:callOnDependencyRemoval
Drupal\Core\Entity\EntityDisplayBase:onDependencyRemoval
The code of these functions seems to be related to #2850973: ConfigEntityInterface::onDependencyRemoval() called with incorrect dependency list.
In short, the reason the problem happens is because:
When the Manage Display Comment page is displayed, a list of all config depending on 'comment.type.comment' is created.
Since the default display of comments 'core.entity_view_display.comment.comment.default' depends on 'comment.type.comment' and since 'core.entity_view_display.node.article.default' depends on 'core.entity_view_display.comment.comment.default' it is also added to the list of dependencies.
core.entity_view_display.node.article.default > core.entity_view_display.comment.comment.default > comment.type.comment
The affected "cross" dependency is due to the fact the Node, type Article, default display 'core.entity_view_display.node.article.default' uses the default comment formatter (to display the Comment field), which points to the default display of the Comment, type Comment 'core.entity_view_display.comment.comment.default', see:
https://git.drupalcode.org/project/drupal/-/blob/9.4.5/core/modules/comm...
In particular lines around 270:
if ($display = EntityViewDisplay::load("comment.$bundle.$mode")) {
$dependencies[$display->getConfigDependencyKey()][] = $display->getConfigDependencyName();
}
From a logic perspective it certainly makes sense to allow the default comment formatter, and Plugins in general to react to configuration changes on Entity Displays.
For example, it would probably make sense adding a specific handling case for the default comment formatter: Drupal\comment\Plugin\Field\FieldFormatter\CommentDefaultFormatter:onDependencyRemoval, to check whether the referenced display still exists and capture any changes to the settings, much like it's currently done for the 'ImageFormatter', see:
https://git.drupalcode.org/project/drupal/-/blob/9.4.5/core/modules/imag...
Work-around/Temporary solution
Note the problem can be fixed temporarily by removing the config dependency either programmatically, or by importing the modified config through the backend (at '/admin/config/development/configuration/single/import/') or from its file (edit file 'config/sync/core.entity_view_display.node.article.default.yml', remove the line 'core.entity_view_display.comment.comment.default' under 'config' and import).
But of course the config is added back the next time the Node Article display 'core.entity_view_display.node.article.default' is saved.
Lastly, since we're really unsure how to approach the problem and the config dependency system seems to have a lot of moving parts, we found the following issues that could potentially be related or where some work is carried around Plugins 'getPluginRemovedDependencies' and 'getPluginRemovedDependencies':
We would greatly appreciate to have your feedback and more particularly, if anyone would have any pointers or guidance on what could be the best approach to finding a solution to the problem.
Feel free to let us know if you have any questions, if anything is unclear or if more information would be needed, we would surely be glad to help.
Thanks in advance.
