From the project page:

It introduces also custom cache tag for the views so it's placing more specific tags for the views. Namely, it places {entity}_{bundle}_pub (like node_article_pub or node_recipe_pub) instead of too general node_list. Placing them out of the box based on the configured filters and contexts in particular view.

This is:

Please help fix this in core! A module that has no security coverage and is already marked as "minimally maintained & maintenance fixes only" will never reach a big audience.

Thank you for publishing this module of course! But now please help make the next step, and help fix the root cause :) 🙏

Comments

Wim Leers created an issue.

fago’s picture

fago
Primary language German
Location Vienna
commented

Thanks for the pointers. We are aware of views_custom_tags, however our solution is more general as it goes beyond views.

Fixing this for bundles in core will be already a big help, however what one really wants to have is cache tags that are aware of the concrete filters of a query. For example, thinking of media sites working a lot with articles, the problem won't really change as still articles are everywhere.

Unfortunately that's not easy to do generically, while possible. Still, writing and invalidation cache tags per field would be unreasonable as a default behavior. Thus it would make more sense to provide a mechanism for simply configuring the entity and field value combinations, that should get cache tags. When then the system could automatically generate cache tags based upon queries and invalidate them based upon changes, that would be really beneficial and help way more than just solving the bundle level as well. Do you think a solution like that would be applicable in core or better be developed in a contrib?