Ajax exposed filters not working for multiple instances of the same Views block placed on one page

Patch in #82 doesn't work for us, it removes the ajax_view.js changes present in #80.

#80 applied to 9.5.5 cleanly and works for us.

tgauges → closed merge request !3685

tgauges → closed merge request !3686

Changing the target branch of the merge request

1. broke our build
2. made the MR have 700+ commits and 1000+ changes

I created a new merge requests against 9.5.x: https://git.drupalcode.org/project/drupal/-/merge_requests/3687.

Patch #80 work for us with Drupal 9.5.8 not with 9.5.9
Patch #82 doesn't work at all...

This issue should be fixed first for Drupal 10 and then backport if it applies.

I left some comments in the MR from #90. I think is the right approach.

Since the project where I need this is in Drupal 9.5.9 you can find attached the patch for convenience. The rebase is quite trivial.

Ugh. Now the non-empty patch

The last submitted patch, 96: 3163299-96.patch, failed testing. View results →

Arghhh, I think I have found source of the issue why tests are so unreliable, and its 🐛 Cached forms can have duplicate HTML IDs, which disrupts accessible form labels Needs work .. I think the fix is correct, but the test is not due to issues with duplicate form CSS ids.

Can the issue summary be updated to include the proposed solution and any remaining tasks.

I have detected that the block preprocess functions are not triggered for the exposed filter blocks when using this patch.

The problem appears because of this file changes

--- a/core/modules/views/src/Plugin/Block/ViewsExposedFilterBlock.php
+++ b/core/modules/views/src/Plugin/Block/ViewsExposedFilterBlock.php
@@ -32,15 +32,17 @@ public function getCacheContexts() {
    *   context of current view and display ID.
    */
   public function build() {
-    $output = $this->view->display_handler->viewExposedFormBlocks() ?? [];
+    $output = [];
+    $build = $this->view->display_handler->viewExposedFormBlocks() ?? [];
     // Provide the context for block build and block view alter hooks.
     // \Drupal\views\Plugin\Block\ViewsBlock::build() adds the same context in
     // \Drupal\views\ViewExecutable::buildRenderable() using
     // \Drupal\views\Plugin\views\display\DisplayPluginBase::buildRenderable().
-    if (!empty($output)) {
+    if (!empty($build)) {
       $output += [
         '#view' => $this->view,
         '#display_id' => $this->displayID,
+        'content' => $build,
       ];
     }

It seems that adding the block render array inside the `content` key avoids to trigger the preprocess functions.

Reroll for D10.2

pyrello → changed the visibility of the branch 10.1.x to hidden.

pyrello → changed the visibility of the branch 11.x to hidden.

pyrello → closed merge request !6791

pyrello → changed the visibility of the branch 10.3.x to hidden.

There is no need to make a new merge request. You can force-push the branch of the existing merge request and it will use the new code. It will leave behind a tag pointing at the old code.

@Liam Moreland Good to know. Not sure I would have figured that out on my own and I have yet to discover the docs indicating the proper workflow with MRs yet.

Tested MR from #116 over core 10.3.5 on views embedded with viewsreference + viewsreference_filter + better_exposed_filter with success.
Thanks a lot !

Uploading patch from MR 6796 #116 for core 10.3.5

patch 120 work for me , thank you

I can confirm the latest patch also solved this issue for us.

Issue summary is still incomplete and there are multiple MRs but don’t appear to be one for 11.x

This patch fixes only views in blocks, but not exposed forms in blocks as in https://www.drupal.org/project/drupal/issues/3032353 ✨ Exposed forms in a block are not currently updated when Ajax filtering is executed Needs work , right?
Trying to find out how to fix conflicts between patches from both issues and apply to project I'm working on now.

laura.j.johnson@gmail.com → made their first commit to this issue’s fork.

The 10.3 patch works to fix the issue with multiple views on a page but we have the issue where exposed filters in media library views break when adding blocks with Layout Builder because there is no ajax applied to them. I have created an MR and attached a patch to use the original form IDs for media library views. We're using Gin LB.

wannesdr → changed the visibility of the branch 3163299-views-multiple-ajax-exposed-filters to active.

@laura.j.johnson@gmail.com

I tried reproducing the media browser issue in vanilla core + layout builder, but I could not reproduce this.
It might be a Gin LB specific issue, which I did not test. If so, gin_lb seems to be the appropriate place to fix this issue.

We discussed this issue at dev days with Lendude & Wannesdr.

For ajax updates of exposed forms, which is required for e.g. Facets 3 users, we need ajax enabled exposed forms exposed in a block to update the form(s) too.
However, some users' usecase is that they explicitly use "expose form in block" to prevent the form from updating, which is the current behaviour.
That's why we suggest introducing an extra setting, only visible when "expose form in block" is set to "yes", which allows users to choose how the block form should behave (update or do not update on form submit). For existing views, we keep the old behaviour as default value.