Currently I am using the quicktab module with two view tabs. Each one is calling a block view showing a list of a certain content type. When a new content is created, the view itself is updated (using the preview) but the webpage with the quicktabs and the views does not.
Cause
The quicktab render array with the 2 tabs does not use a cache so when a new content is created the view is updated but the quicktab render array does not.
I created a patch invalidating the cache of the quicktabs render array. I think there is gotta be another way to improve this solution.
Suggestions welcome ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | quicktabs-cache-does-not-work-2979578.patch | 386 bytes | amarincolas |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
amarincolas commentedComment #3
amarincolas commentedComment #4
amarincolas commentedComment #5
awasson commentedHas there been any movement on this issue?
I think this may be related to an issue I am having with 3 tabs in View based Block.
The Tabs are rendered in a view that depends on a Contextual Filter (Paragraph: Parent ID) to render and is placed on the page content in a block.
Right out of the gate it works well and has for the last year but we noticed a problem. If we update the tab content, the changes do not show up in the rendered view. They do show up during editing but not when rendered.
Comment #6
shelaneI would like to get this into ViewContent and NodeContent somehow. First, the proposed page is a renderer style. So any other style would also have to add this, which includes modules outside of this one. I think if it can be done in the TabTypes, that would make most sense. I will continue to look into this.
Comment #7
smustgrave commentedComment #9
joelpittetReviewed this after the recent #3408869: drupal_flush_all_caches is problematic cache work.
I do not think #3408869: drupal_flush_all_caches is problematic fully fixes this issue, since it covers QuickTabs instance config changes and derived block discovery.
For this report, #3390465: Cache metadata of individual blocks are not taken into account when rendering blocks in quicktabs seems more directly related. It fixed cache metadata bubbling from blocks rendered inside QuickTabs, which should cover Views blocks in tabs so new matching content invalidates the rendered output through normal cache tags.
I'll see if I can get some tests to show if it's fixing this or not before closing as a duplicate however.
Comment #11
joelpittetThanks everyone who helped move this along.
I reviewed this against the current 4.x code and added regression coverage for the reported case: a QuickTabs block with a Views block tab that starts empty, then shows new matching content after it is created.
This appears to be covered by the cache metadata work from #3390465: Cache metadata of individual blocks are not taken into account when rendering blocks in quicktabs, which preserves cacheability from blocks rendered inside QuickTabs. Since Views blocks provide the relevant cache tags, the cached QuickTabs output now invalidates correctly.
Closing this as fixed by that, with test coverage added here to confirm the original scenario.