- 🇬🇧United Kingdom joachim
Rather than adding new subdivisions of list caching one by one, I wonder whether we could add something generic: see 📌 Segmented ENTITY_TYPE_list:* cache tags Active .
The node_list cache tag is very generic. We've already introduce a list cache tag per bundle #2145751: Introduce ENTITY_TYPE_list:BUNDLE cache tag and add it to single bundle listing → and are looking at how to use it - 🐛 Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate Needs work . But there is another issue. Every time an unpublished node is edited or a draft created the list cache tags are invalidated. This means that an editor doing small edits to an article whilst preparing an article is behaving like a cache buster for any views that list nodes - for example taxonomy listing, recent content and the frontpage view. Since the node is unpublished none of these changes will cause any real changes.
Introduce an published list cache tag and work together with 🐛 Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate Needs work to work out how views filters can alter the list cache tags of a view.
Active
10.1 ✨
It affects performance. It is often combined with the Needs profiling tag.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Rather than adding new subdivisions of list caching one by one, I wonder whether we could add something generic: see 📌 Segmented ENTITY_TYPE_list:* cache tags Active .