The real issue is that the plugin will sometimes be returning render arrays that are discrete block displays from the same view, possibly also with different arguments. What I'm discovering is that in these cases, the first render array is cached so that the subsequent displays are the same as the initial one. I'm building the render arrays with buildRenderable($display_id, $args, FALSE), which will apparently disable tag and keys caching. But, I'm unclear how to manually provide a custom cache context without a varying request.

  • This is related drupal.stackexchange.com/questions/307728/…. The best strategy for your custom cache context depends on how many variations this context is producing.
    – 4uk4
    Apr 25, 2022 at 17:02
  • I've seen the issue you referenced, could you elaborate on what you mean in your comment @4uk4?
    – Steve
    Apr 25, 2022 at 17:14

2 Answers 2


But, I'm unclear how to manually provide a custom cache context without a varying request.

There are three strategies:

  1. Add the custom cache context to the render array, then the cache context bubbles up to the block and page adding variations on each level upstream.

  2. Add a lazy-builder and set the property #create_placeholder. Then the custom cache context doesn't bubble up anymore. Instead the cached block and page includes the placeholder which gets replaced by the lazily built content later when the cached page is delivered.

  3. Add a cache max-age of 0. Blocks are already built in a lazy builder and are placeholdered if the content meets the auto-placeholder condition. This results in a block never cached and always placeholdered.

Use the first option for a cache context not having too many variations. The second option is a bit more effort to implement, since Drupal 8.8 you need an extra class implementing TrustedCallbackInterface or RenderCallbackInterface, but is more flexible to define static and dynamic content, even within the same block. Easier is the third option, use this if the block content is so volatile that caching is not worth the effort.

  • Does it make sense that the content variable in the template contains two distinct render arrays?
    – Steve
    Apr 25, 2022 at 20:54
  • Yes, often you use containers to separate them in a renderable structure which is also themable. See api.drupal.org/api/drupal/…
    – 4uk4
    Apr 25, 2022 at 21:46
  • I guess what I was asking is, the content variable in the template contains the correct render arrays, using the discrete view display ids. However, they are not in the end rendered as distinct, which is the problem I'm having. I'm simply rendering the content with {% for value in content %} {{ value }} {% endfor %}.
    – Steve
    Apr 25, 2022 at 22:52
  • Normally the variable name content in a Drupal template is a render array rendered recursively like any other render array without assuming a specific structure. If you have control on both ends of the variable you could make such assumptions, but I wouldn't do this. If someone else is not aware of that and deletes the customized block template or switches to a different theme not containing this template things will break.
    – 4uk4
    Apr 26, 2022 at 7:04
  • If you need to render separate variables then add a custom template to your module for the inside and use the block template to theme the outside of the block if necessary.
    – 4uk4
    Apr 26, 2022 at 7:09

In the end, I could not for all these suggestions, get the first array not the cache. This could still be due to a deficiency in my process, but I finally just used two discrete views, rather than trying to get the arrays to vary on the display id for a single view.

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.