See views_theme_suggestions_node_alter(), and views_theme_suggestions_comment_alter(), also the code in views_preprocess_node() and views_preprocess_comment() actually.
That does stuff on $node->view. Which is assigned by views when displaying a node. But there is no cache context for this, can't really be, so it is not cached correctly.
Related to 🐛 template_preprocess_node() does not add cacheability metadata Needs work as well.
The only thing I can think of is to implement hook_entity_build_defaults_alter() and there, based on the view id and display, define a cache key. The obvious downside is that it results in more cache variations.
I'm also not 100% sure that it is completely accurate then. hook_entity_build_defaults_alter() has some limitations, if dynamic page cache doesn't know about those conditions. But that already has to know about the view/display, if not, you already have a problem.
I think as a long term solution, we should deprecate $node->view and everything that depends on it, but there is no way to make that obvious in something like twig theme suggestions debug output, so people will continue to use it.
Postponed
11.0 🔥
views.module
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This issue just destroyed my day, FWIW, in Drupal 10.3 no less.
I have added a bug report with suggested revisions to the documentation as a temporary fix.
https://www.drupal.org/project/drupal/issues/3479114
📌
Warn about node--view suggestions that do not work
Active