Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
In the process of triaging issue #2823541: Table clicksort is lost when using views exposed filter & Pager exposed '#items' @xjm and I encountered another problem relating to the views exposed block form where the options and/or widgets displayed on the exposed block were not immediately visible on the view page after changing the configuration of the view itself.
Steps to reproduce
- Add some content into a default new standard profile 8.4.x HEAD D8 site
- Create a page view (with URL /sortmissing), add exposed filters for sorting criteria (eg. content type for filter and authored on, authored by, for sort criteria)
- Add a full pager with exposed option "Allow user to control the number of items displayed in this view"
- Under Advanced config of the view, select Yes for Exposed Form, choosing Basic form type
- Under Structure - Block Layout - Place Block choose the newly created exposed form and place it in a region (eg. Sidebar)
- Go the view page (/sortmissing), notice which options and widgets are shown
- Change the view and add another option into an existing filter (eg. add Title to the Sort Criteria so that you have three options: authored on, authored by and title as options there)
- Switch back to view page and just refresh the page or click Apply on the exposed block form to refresh the display - the resulting page does not show the newly added option
Based on how unpredictable the display of the exposed block options happens as it eventually refreshes after a few attempts clicking on the page and the various options (usually after 3-4 refreshes of changing the chosen filtering options things seem to update), this would possibly be related to caching and how the cache is being invalidated on the exposed filters block for the view.
Attached with the issue is the export of the view I've used to arrive at the issue.
- - - - - - - - - - - - - -
This issue emerged from #2823541: Table clicksort is lost when using views exposed filter & Pager exposed '#items' and the following folks deserve credit:
@anneeasterling = #2823541-9: Table clicksort is lost when using views exposed filter & Pager exposed '#items'
@krknth = #2823541-10: Table clicksort is lost when using views exposed filter & Pager exposed '#items'
Proposed resolution
Override getCacheTags method and pass relevant cache tags.
public function getCacheTags(): array {
$tags = parent::getCacheTags();
// Add the tag for the View this block belongs to.
return Cache::mergeTags($tags, ['config:views.view.' . $this->view->id()]);
}Remaining tasks
Needs review
User interface changes
N/A
API changes
N/A
Data model changes
N/A
| Comment | File | Size | Author |
|---|
Issue fork drupal-2887144
Show commands
Start 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
samirjusic commentedI searched through the existing views issues list for 8.4.x, but could not find an existing bug reported so I'm raising the new one here.
Comment #3
stpaultim commentedWorking on Major Issues Triage at Twin Cities Drupal Camp with @mathuaerknedam (mentored by @YesCT)
This issue appears to have emerged from #2823541: Table clicksort is lost when using views exposed filter & Pager exposed '#items' and the following folks deserve credit:
@anneeasterling = #2823541-9: Table clicksort is lost when using views exposed filter & Pager exposed '#items'
@krknth = #2823541-10: Table clicksort is lost when using views exposed filter & Pager exposed '#items'
Comment #4
stpaultim commentedComment #5
stpaultim commentedComment #6
Anonymous (not verified) commentedxjm credited anneeasterling.
Comment #7
xjmAdded credit for anneeasterling who originally identified this issue. krknth reproduced the other issue but did not identify this one, so they'll receive credit for the other. Thanks @StPaulTim!
Comment #8
micbar commentedI have an exposed filters form on a block which contains a list of taxonomy terms. If I add a new term to the vocabulary, the exposed filters form does not get updated. Digging into the block object shows only one cache context "languages:language_interface" and no cache tags. Is that use case (taxonomy terms in exposed filters form) not working by default and needs some tweaking or is it a bug in the views module?
Comment #10
lendude@micbar that sounds like #2900248: Exposed term filter is not updated when terms are added, deleted, or rearranged (caching issue?), not sort criteria which this issue is talking about.
I can reproduce this issue, but took me a while to see that the essential point here is that it is about the 'Exposed form in block:Yes' block.
Fix in the patch fixes it for me when manually testing, but this obviously still needs tests.
And is there any way to get the tag
'config:views.view.' . $this->view->id()from the View and not have to build it yourself? Couldn't find anything.Comment #12
borisson_I don't see a better way to do this.
Setting to needs work to add the needed tests.
Comment #20
larowlanComment #21
karishmaamin commentedRe-rolled patch against 9.4.x. Please review
Comment #22
yogeshmpawarComment #23
kumudbAdding against 9.4.x
Comment #24
kumudbPatch against failed previous path.
Comment #25
kumudbComments against #23
Comment #28
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
For the tests requested in #10.
Also the issue summary could use an update as it references D10 a lot.
Comment #29
smustgrave commentedComment #30
mohit_aghera commented- Added a test-only patch and test cases for the issue.
- Patches #23 #24 and #25 are completely wrong and without any direction.
- Interdiff is taken against patch #21
- Updated issue summary as well.
Comment #32
mohit_aghera commentedComment #33
smustgrave commentedIssue summary looks good.
Tests-only patch in #30 shows the failure I think perfectly, good job @mohit_aghera!
Applied cleanly and everything appears to function as normal.
Comment #35
borisson_Looks like the latest patch fails.
Comment #36
mohit_aghera commentedTriggering the test bot again for patches in #30.
Failures are in
CkEditor5\FunctionalJavascript\MediaTestComment #38
mohit_aghera commentedComment #41
mxr576let's start with a clean up
Comment #42
mxr576Comment #44
mxr576The failing test confirms that even with #3493858: Extend ViewsBlockBase to merge cache metadata from display handler merged into Drupal core, this issue still persists. The cacheability metadata from the View config entity is still not bubbling up to the block, so the underlying problem remains unresolved.
Relying on
View::getCacheTags()should be a better solution instead of a hand-crafted config cache id, since\Drupal\views\Entity\View::addCacheMetadata()ensures that before a View config is changed display plugin's cacheability information is also incorporated into the stored cache tags.Question: What about cache contexts and cache max age bubble up from the View entity?
The merge request is currently failing due to the test coverage introduced in #3493858: Extend ViewsBlockBase to merge cache metadata from display handler, which added significant amounts of mocking. Somebody has to fix those, because I tried and failed miserably due to interconnected dependencies and protected properties... (This is one of the main reasons I try to avoid overusing mocks in my own projects - they tend to make the test suite fragile and harder to maintain.
</personal_opinion>)(There may also be a related issue in the contrib space: #3523416: Filter configuration changes does not propagate immeditelly to BEF in a block.)
Comment #45
xjmAmending attribution.