Join Log in
Score:0
avatar Drupal

Which cache should I invalidate in a block plugin that builds render arrays for one or more views?

in flag
steve

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.

86
0 + 0
4uk4 avatar
cn flag
4uk4
This is related https://drupal.stackexchange.com/questions/307728/render-view-inside-block-with-caching. The best strategy for your custom cache context depends on how many variations this context is producing.
0
Reply
in flag
steve
I've seen the issue you referenced, could you elaborate on what you mean in your comment @4uk4?
0
Reply
Score:1
4uk4 avatar Drupal
cn flag
4uk4

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.

0 + 0
in flag
steve
Does it make sense that the `content` variable in the template contains two distinct render arrays?
0
Reply
4uk4 avatar
cn flag
4uk4
Yes, often you use containers to separate them in a renderable structure which is also themable. See https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21Element%21Container.php/class/Container
0
Reply
in flag
steve
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 %}`.
0
Reply
4uk4 avatar
cn flag
4uk4
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.
0
Reply
4uk4 avatar
cn flag
4uk4
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.
0
Reply
in flag
steve
I think I'm probably not being clear. What we're discussing is a custom module, with a block plugin class that returns one or more view blocks as render arrays in the `build` method. These render arrays are themed in a custom block template in the module. My question in these comments about the `content` variable that is passed to the template is this: Does it makes sense, with regard to the issue I'm having with render array caching, to have the _correct_, distinct render arrays passed to the template, which are still nevertheless being finally being incorrectly rendered as the same?
0
Reply
4uk4 avatar
cn flag
4uk4
We are discussing the same, the difference is that I'm suggesting these render arrays are themed in a custom template which is not a block template. See https://www.drupal.org/docs/theming-drupal/twig-in-drupal/create-custom-twig-templates-for-custom-module#s-step-33-render-as-part-of-another-plugin-such-as-block.
0
Reply
in flag
steve
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/135849/discussion-between-steve-and-4uk4).
0
Reply
Score:0
avatar Drupal
in flag
steve

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.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

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.