Score:2

Drupal

How to programmatically invalidate the cache of every node

Matt

1/25/24, 10:19 PM

I have a form submit function that is meant to invalidate the cache of every node if a specific field is altered. Here's how I'm attempting it.

$config = $this->configFactory
  ->getEditable('my_config.settings')
  ->get();
if ($form_state->getValue('global')['header_button'] != $config['global']['header_button']){
  // Header Button Changed
  \Drupal\Core\Cache\Cache::invalidateTags(['node_list']);
}

From what I've researched I assumed \Drupal\Core\Cache\Cache::invalidateTags(['node_list']); would invalidate the cache on every node, but the changes to the nodes are not appearing to anonymous users. Not sure if it matters but the change that is made affects what is rendered in region--header.html.twig rather than node.html.twig.

I've looked at How do I invalidate the cache of an entity? but the answers there did not work.

427

1 + 7

caching

Jaypan

1/25/24, 10:37 PM

What is your use case? You are almost definitely trying to apply a sledgehammer approach to a situation that needs finesse, but you haven't explained your use case for us to be able to advise you accordingly. That said, you should be able to do it with `\Drupal\Core\Cache\Cache::invalidateTags(['node']);`, but it's a sledgehammer solution and the performance on your site will take a hit, particularly if you have a lot of nodes.

cilefen

1/25/24, 10:38 PM

I am trying to decide if it is really necessary to explicitly invalidate tags in this case. Does the changing content have caching metadata?

Jaypan

1/26/24, 12:01 AM

I would probably add the cache tag for this config key to the field in question, negating the need to invalidate anything as the system would handle it.

Matt

1/26/24, 1:29 AM

@Jaypan The reason why every node needs to be invalidated is because I've built a custom config that allows the admin to globally add a button that appears on every page. Because this appears on every page each node would need to be invalidated.

Jaypan

1/26/24, 2:55 AM

See my above comment

unusedspoon

1/26/24, 9:09 AM

Sounds like your button should be a block shown on all pages. Then you'd just clear the cache for your 1 block

Jaypan

1/26/24, 3:05 PM

yeah, I'm not even sure that it should be part of the node. We never got a use case, so it's hard to provide specifics.

Score:1

Drupal

4uk4

1/26/24, 7:35 AM

The node_list cache tag is indeed invalidated by every node change but it's not the other way, that it invalidates every node. The cache tag is only added to the result of node entity queries, not to single nodes.

For a configuration change, it's OK to invalidate the entire render cache, at least for a typical configuration option not changed in the normal operation of the website. For example, Drupal core does the same when theme settings are saved. This is not as time-consuming as clearing the entire Drupal cache:

Cache::invalidateTags(['rendered']);

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How to programmatically invalidate the cache of every node

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.