I'm working with a site which has page cache enabled.

I'd like the page cache for any given node to invalidate when that node is changed. There's a lot of examples out there dealing with cache tags, but I haven't had any luck figuring out the relationship between page caching and cache tags.

I've got a node which starts out being published. I then unpublish it, and publish it again. When I publish it for the second time, the page cache still treats it as unpublished. It does so until i clear the entire (page) cache.

It seems that the cache_page entry is updated when i update a published node, but whenever the node goes from unpublished to published - the page cache entry doesn't follow.

I've tried implementing hook_entity_update and do a Cache::invalidateTags(['node:19']);, but that had no impact.

Is it possible to use cache tags to invalidate page cache entries?

  • I'd like the page cache for any given node to invalidate when that node is changed. – that's already built in. But it depends how and where exactly this node is being displayed. You probably need to update your question clarifying that. – leymannx Sep 1 '20 at 12:19
  • @leymannx updated question to reflect that. If this is already built in, it may be a bug then. – sbrattla Sep 1 '20 at 12:24
  • Are you on the node view or are you talking about for example a view where the node is displayed? – sanzante Sep 1 '20 at 12:25
  • 1
    You didn't add how the node is being displayed. The cache tags only invalidate cache for things when the tags are appropriately added to render arrays. – sonfd Sep 1 '20 at 12:26
  • 1
    Can you add which page caching modules you have enabled, also whether there are any external cache mechanisms, e.g. varnish. – sonfd Sep 1 '20 at 12:30

Page cache is just the cached values.

Cache tags are tags that are attached to a cached value (simplifying a little bit). This tells Drupal what cached values are related to what cache tags. When a cache tag is invalidated, all cached values that have the invalidated cache tag are invalidated as well. You can find more info on the Drupal documentation page about Cache Tags. The headline is:

Cache tags provide a declarative way to track which cache items depend on some data managed by Drupal.

So, answering your question, yes, they are totally related and you can (and you should) invalidate page cache entries using cache tags. Because, as stated above, cache tags track content and cache dependencies and thus you can invalidate cached item when content (or the source data of a cached item) changes.

However, this can be tricky. For example, page cache entry of a node view page is always associated with the cache tag node:[nid]. When the node is updated, that cache tag is invalidated, thus making the page cache of that node's view page invalidated as well. Views that shows a list of nodes are not associated with each node's cache tag. Blocks are other display elements may not be related to that kind of tags. So you need to know which cache tag you want to invalidate.

The good news is Drupal takes care of the most common cases, so you don't have to care. Usually, you only need to deal with the cache tags when you are developing custom code.

In your case, you may be hitting another cache (browser cache? reverse proxy cache?).

  • It seems that when you unpublish a node, the page cache sets the checksum for the node's url alias to 0 and removes all tags in the cache_page table. If you publish the node again, there are no tags in cache_page to target. So the page cache table seems to just serve out stale content. – sbrattla Sep 1 '20 at 12:42
  • Yes, this could be the reason. But as @sanzante answered, Drupal takes care of the most common use cases. When you try to display an unpublished node and produce an access denied result this bubbles up the cache tag of the node to the page and Views filtering for the published status usually adds a node_list tag catching all node saves. – 4k4 Sep 1 '20 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.