Problem/Motivation
The taxonomy_tid Views argument default plugin doesn't set any cache tags. And it extends ArgumentDefaultPluginBase, which also doesn't set any cache tags.
But clearly if the plugin is configured to use the node being viewed, the cache tags of said node should be returned by the plugin.

Steps to reproduce
In most cases this won't be noticed because the node_list cache tag tends to be on the View. But using a module like views_custom_cache_tag, I could put a Views block on a Page node that only serves Article nodes and only has the `node_list:article` cache tag. Then if I edit the Page and change the terms that it references and reload the Page, I would see that the View block does not update.
Proposed resolution
Add getCacheTags() method to Drupal\taxonomy\Plugin\views\argument_default\Tid
Remaining tasks
User interface changes
nope
API changes
nope
Data model changes
nope
Release notes snippet
nope
| Comment | File | Size | Author |
|---|
Issue fork drupal-3427374
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:
Comments
Comment #2
danflanagan8Here's a View I built out to help reproduce that follows what's in the IS. I did a Standard install and added field_tags to Page content type. Then I put this block in the content region of the block layout. Indeed when I view a Page and then update its tags, the View block does not update to reflect that change.
Comment #3
danflanagan8Comment #4
vighneshh commentedI have added a patch that would invalidate the cache and add cache tags according to the taxonomy ID.
Comment #5
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue.
While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)
Comment #6
danflanagan8@Vighneshh I don't understand why the terms would need their cache tags added. What's a scenario where those cache tags would be relevant?
Also adding the Needs test tag. I'm hoping we can just add some assertions to existing test cases in `Drupal\Tests\taxonomy\Kernel\Views\TaxonomyDefaultArgumentTest`.
Comment #8
danflanagan8I put in an MR with a fix and some tests.
I've thought a bit about my claim in #6 that we don't need the cache tags of any of the terms. We don't access any fields on any of the terms that might be returned, so the only relevant aspect of the terms that might change is the publish status. Of course, publish status would be handled by the validator plugin, not the argument_default plugin. All in all, I'm pretty confident we don't want to use the terms' cache tags.
Comment #9
smustgrave commentedCan the MR be updated for 11.x please
Comment #11
danflanagan8Comment #12
danflanagan8Comment #15
danflanagan8Comment #16
smustgrave commentedTest-only job was ran already https://git.drupalcode.org/issue/drupal-3427374/-/jobs/1534215 won't post the output as it's large.
But looking at the solution this would only work for nodes right? What about other entity types?
Comment #17
danflanagan8> But looking at the solution this would only work for nodes right? What about other entity types?
The feature itself only exists for nodes, and the option text is clear about that:
Load default filter from node page, that's good for related taxonomy blocksSo that's all the caching we have to worry about too.
Comment #18
smustgrave commentedOh didn't see that.
As mentioned in the summary hard to test this manually but believe the tests show the issue. So believe adding should be fine.
I don't believe this will need a CR but I've been wrong before.
Comment #19
catchIt might be worth a follow-up to make this work for any entity type, we could add an 'entity' option and deprecate the node one probably. MR looks fine but I'm short for time and didn't review enough to actually commit.
Comment #24
alexpottSure we can open an issue to make this option not limited to just node but that does not feel like a specific follow-up of this issue.
Committed and pushed 6d3cdb7701 to 11.x and 10be645825 to 11.0.x and 99ed4332d1 to 10.4.x and e4a770899b to 10.3.x. Thanks!
I was wondering about upgrade paths because cache tags appear in views config - but these cache tags sure don't because they are way more dynamic.
Comment #26
danflanagan8It tuns out this fix doesn't really do anything because Views do not calculate cacheability of argument_default plugins at runtime. D'oh!
The same goes for argument and argument_validator plugins as well. The fun will continue in #3091671: Validate user has access option in contextual filter does not bubble access cacheability for views page
Comment #27
ericgsmith commentedShould this be reverted - or open a new issue to revert? As mentioned above - this does nothing and the issue still persists. Cache tags returned by the handler are added to the view when the view is saved, not at runtime.
#3091671: Validate user has access option in contextual filter does not bubble access cacheability for views page looks related but not general enough that it would solve this issue. I will open a new issue in a couple days unless the etiquette is to reopen this