1

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.

  • 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 Feb 10 '17 at 3:26
  • @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 Feb 10 '17 at 16:18
0

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.

  • 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 Feb 10 '17 at 17:42
0

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;   
    } 
}

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.