Problem/Motivation
There is ENTITY_TYPE_list cache tag and it is being invalidated very often. For example, if we have 20 different content types and created views page to display the list of content for each type, then whenever editor adds/edits/deletes one of the content - all 20 views pages will be invalidated BUT only related should be invalidated, others still have no changes. So, it means that on current sites if somebody changes something then Drupal will clear cache for almost the entire website.
Proposed resolution
Add bundle specific list cache tags - ENTITY_TYPE_list:BUNDLE
Also:
- Rename
getListCacheTags
togetListCacheTagsToInvalidate
. - Add
getListCacheTags
in the follow up where we determine bundle specific cache tag based on query object.
so that listing pages can add bundle specific list cache tags or generic list cache tags
Remaining tasks
Write tests as per #93.5- Create change record.
- Open follow-up issues for views, search_api and other modules that will require an update.
Release notes snippet
Added an ENTITY_TYPE_list:BUNDLE cache tag for all entity types with bundles, e.g. node_list:article, which allows for more targeted cache invalidation in custom code and views in combination with a module like Views Custom Cache Tag
Original report by [effulgentsia]
Follow up from #1712456: How to leverage cache tags in Views.
Two problems:
- That issue changed EntityViewBuilder::resetCache() from just clearing the TYPE:ID tag to also clearing the TYPE_view_BUNDLE tag. However, what is the meaning of this tag? What does it mean to "view" a bundle? #1712456-50: How to leverage cache tags in Views says "Say you save settings for one node type, it would invalidate caches for every node on the system?!", so ok, if the intent of this tag is to clear caches upon a change to the settings of a bundle, then why is it being cleared upon the saving of a single entity, which is when EntityViewBuilder::resetCache() is called? OTOH, the same comment also says We need a way like this to invalidate 'lists' containing this entity type. This and 'view' could be similar though I guess.. Hm, if the 'view' here refers to lists (where Views module is the most common list generator) rather than to the 'view' in the sense of EntityViewBuilder, then let's rename this tag to 'list' instead. If we then also want a per-bundle 'view' tag for clearing when bundle settings change in a way that would affect their display, then that's what we should use 'view_BUNDLE' for, but then clear it only where bundle settings are managed (e.g., EntityDisplay) rather than in EntityViewBuilder::resetCache().
- If we do rename this to TYPE_list_BUNDLE, then how should we handle Views that are cross-bundle? For example, currently in HEAD, if I enable tag-based caching on the front page View, then visit the front page at a time when only Article nodes are promoted to the front page, then I add a Page node and promote it, it doesn't show up on my front page until I manually clear caches. Perhaps we need a non-bundle-specific TYPE_list tag as well, and add that to all cross-bundle Views, but not to Views and EFQ listings that we know are bundle-specific?