Problem/Motivation

Steps to reproduce:

  1. Install Drupal (standard profile)
  2. Edit the "Content" view (/admin/structure/views/view/content)
  3. Add an exposed filter for the "Tags" (field_tags) field. Make sure to "Dropdown" as "Selection type".
  4. Change "Exposed form in block" to "Yes"
  5. Save the view
  6. Go the block layout page for the "Seven" theme (/admin/structure/block/list/seven)
  7. Click the "Place block" button next to "Content"
  8. Click "Place block" in the "Exposed form: content-page_1" row
  9. Restrict the visibility of the block by page: "/admin/content" (not necessary but to avoid confusion)
  10. Click the "Save block" button the block configuration modal
  11. Navigate to the "Content" page (/admin/content).
  12. You will see the exposed block with the "Tags" filter being empty.
  13. Add a new term "Test" in the "Tags" vocabulary (/admin/structure/taxonomy/manage/tags/add)
  14. Visit the content page again (/admin/content). The "Tags" filter is still empty.

Expected behavior: you can select "Test" in the "Tags" filter.

There is already another issue about terms in the exposed filter not updating @ #2900248: Exposed term filter is not updated when terms are added, deleted, or rearranged (caching issue?). That ticket is specific to the taxonomy term filter when the exposed filters are not displayed in a block. Applying the (working) patch in that issue will not resolve this issue.

Proposed resolution

The \Drupal\views\Plugin\BlockViewsExposedFilterBlock plugin inherits the cache contexts of the views display handler. This doesn't appear to be the case yet for cache tags.

Comments

rp7 created an issue. See original summary.

rp7’s picture

Issue summary: View changes
rp7’s picture

rp7’s picture

Status: Active » Needs review
wim leers’s picture

Title: Views Exposed Filter Block not inheriting the display handlers cache tags » Views Exposed Filter Block not inheriting the display handlers cache tags, causing filter options not to appear
Status: Needs review » Needs work
Issue tags: +D8 cacheability, +Needs tests

Wow, great catch! 👏

The steps to reproduce are wonderfully precise. Which should make it easy to turn this into a failing test! That'd make this much easier to fix in Drupal core :) Marking "Needs work" for that.

wim leers’s picture

There is already another issue about terms in the exposed filter not updating @ #2900248: Exposed term filter is not updated when terms are added, deleted, or rearranged (caching issue?). That ticket is specific to the taxonomy term filter when the exposed filters are not displayed in a block. Applying the (working) patch in that issue will not resolve this issue.

Wouldn't solving this issue also solve #2900248: Exposed term filter is not updated when terms are added, deleted, or rearranged (caching issue?)?

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

undersound3’s picture

I am experiencing this on a site using drupal 8.8.1.
Does anybody know of a workaround/patch?

Thanks

finex’s picture

@undersound3: did you try patch #4?

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

askibinski’s picture

StatusFileSize
new705 bytes
new636 bytes

There is an error in the patch in #4. Here is a new one. Still needs tests though.

kapilv’s picture

Status: Needs work » Needs review
StatusFileSize
new7.82 KB

patch applied cleanly. need review

porchlight’s picture

Status: Needs review » Reviewed & tested by the community

Patch worked for me in combination with the patch from the other issue mentioned in the description - https://www.drupal.org/project/drupal/issues/2900248#comment-13795169

Thanks!

catch’s picture

Status: Reviewed & tested by the community » Needs work

Per #13 we need to add an automated test here to show the fix works.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mxr576’s picture

Status: Needs work » Closed (outdated)

I would consider this an outdated issue, I have tried to reproduce the issue by following the manual steps on 11.x today and I could not.

My gut says that this issue was resolved in #3493858: Extend ViewsBlockBase to merge cache metadata from display handler since the merge was merged fix is similar to #13.

Please re-open if you disagree.

xjm’s picture

Saving credits according to our core issue credit guidelines. Thanks!