2

I have created custom blocks in the Custom Block Library and placed instances of the blocks on a page in Block Layout. The blocks get cached for anonymous users.

Editing the custom block and saving does not invalidate the cache for those instances of the blocks. Looking in the "cache_render" table I see that caches for blocks get created through the Custom Blocks Library are set to never expire as a default with no options I can see available in the admin UI.

I have to actually "Flush All Caches" using the Devel module to have the changes appear, or another way I have found is to go to the Block Layout page and click the "Save Blocks" button without changing anything. The cahces for all the blocks will invalidate.

I don't want to give access to Devel to an average content manager or have to try to explain that they have to do a non-obvious extra step to have their block content changes appear. Am I missing a setting in the UI that will invalidate the cache of those blocks on edit save?

I can cobble together a module that would add an extra submit handler that would invalidate the cache using \Drupal::service('cache_tags.invalidator')->invalidateTags() if I can get the cachetags for all instances of the block on save ... but I'm not sure how to get that info, and that just seems like a hack.

I'm hoping I'm just missing something.

Improve this question
2
  • You have the right idea on invalidating the cache using cache tags. But rather than pulling the cache tags from the block, you should set them as something that can be determined without the need to do so. For example if your custom block is based around a user entity, you may want to set the cache tag as #custom_block-user-[UID] or something like that.
    – Jaypan
    Commented Feb 10, 2017 at 3:26
  • 1
    @Jaypan Since these blocks aren't ones that I've created programmatically but created through the standard admin UI, I'm not setting the cache tags, Drupal assigns the tags. I would think that any update made to to those blocks would handle invalidating cache like updates to nodes seem to do. But, since that doesn't seem to be the case, I've thought about hooking into the block form submit and doing it myself if I could get all instances of the block's cache tags. I just don't want to do something that seems hackish if there is any standard way to force these UI created blocks to invalidate.
    – demarts
    Commented Feb 10, 2017 at 16:18

2 Answers 2

Reset to default
1

Setting max age to 0 saved my day 

function MODULE_NAME_preprocess_block(&$variables) {
    if ($variables['base_plugin_id'] == 'block_content') {
        $variables['#cache']['max-age'] = 0;   
    } 
}
Improve this answer
1
  • You saved me! Thanks a lot. This works like a charm.
    – Lub
    Commented Dec 14, 2022 at 3:47
1

I came across this question in the related questions sidebar on my question that seems to be the same issue with out-of-the-box core blocks: Block cache not clearing on save?

The accepted answer from @4k4 on that question seems to confirm the issue, but doesn't hook in to the block save to invalidate the cache like I was thinking, but mentions, as one possible workaround, adding this to the theme:

function mytheme_preprocess_block(&$variables) {
  if ($variables['base_plugin_id'] == 'block_content') {
    $renderer = \Drupal::service('renderer');
    $renderer->addCacheableDependency($variables, $variables['content']['#block_content']);
  }
}

I don't know if this is the best answer, but it's simple and straightforward and seems to work at the moment, though it's a wonder that this would need to be done at all. It's probably less of a hack than what I was thinking.

Improve this answer
1
  • I had a similar issue, and the solution was to render the {{ content }} field in the block template because it otherwise won't bubble up. That solved it, and I relented to doing {{ content|without('field_foo', 'field_bar', etc) }} because the twig template needed a very specific markup.
    – Kevin
    Commented Feb 10, 2017 at 17:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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