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