Exposed forms in a block are not updated by AJAX

Nice one.
One small improvement.
"usesExposedFormInBlock()" returns TRUE for page display even when not using exposed block.
Changed to "getOption('exposed_block')" as in \Drupal\views\Plugin\views\display\DisplayPluginBase->viewExposedFormBlocks().

+++ b/core/modules/views/src/Controller/ViewAjaxController.php
@@ -200,6 +200,21 @@ public function ajaxView(Request $request) {
+          $response->addCommand(new ReplaceCommand("#views-exposed-form-" . $view_id, $this->renderer->render($exposed_form)));

this will run into problems when #2894747: Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page is fixed

Works well. Thanks, @Vladimirrem for the patch. #9 works for me.

Before this is ready, we need to add an automated test for this. And like I said in #12, this will break once that bug fix lands, so we should probably postpone on this #2894747: Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page

The patch #9 brokes facets work if Exposed Form Block is not displayed on the page.

Because we send replaceCommand anyway. But in ajax.js in insert function of Drupal.AjaxCommands.prototype $wrapper variable will be empty, because selector doesn't exist on the page.

In this case, detach behaviors will be triggered with the whole document context. And in ajax_view.js in Drupal.behaviors.ViewsAjaxView.detach all views instances will be removed, and facets become broken because they use these settings. They stop working.

I remade this patch. We need to send an option if the exposed form is displayed.

I tried #9, but that didn't solved my problem. Any other solution?

Re-rolled it against 9.3.x as it was not getting applied for 9.3.x. So had to do it manually.

Tried to fix test case failure

#22 worked for me on Drupal 9.2. Allowed a faceted search page to work with both a Full text Views filter field in an exposed form block, and a number of facets in their own blocks, with AJAX enabled on the view.

#22 did not apply for me in 9.2 I had different code base.

I rerolled it for 9.2 if anyone wants to have it but for 9.3 #22 works fine.

I am not sure why it fails to apply in 9.2... test is run against the dev branch I guess, I have tested against 9.2.2 and 9.2.7

Considering #22.

Would there be a clean way to keep the input after the ajax refresh (Even if the filter was not submitted)?

E.g. You have a fulltext field exposed in your ajax view. You type something but never submit. Then you select a facet value and the exposed filter is refreshed and loses it's value.

I removed a redundant if statement (see interdiff), and tested #22 in a view with facets / fulltext exposed filter and a custom views exposed filter with multiple input fields. It worked fine so far.

About #25, someone could make the case that it is abysmal UX to have half your filters using ajax and the other half needing a submit button, but I still think that AT LEAST for textfield inputs, autosubmit feels a bit weird.
If we are not to tackle this issue though, I think this could move forward.

Hi, #26 works well except it adds an extra conditional that does not allow any other View Ajax refresh not initiated by the Exposed block itself to re-render/Ajax replace the block. E.g Facets.

I feel that this line where $exposed_form_display is checked to be present (added only for invocations generated by the exposed block itself)

 if ($exposed_form_display && $view->display_handler->usesExposed() && $view->display_handler->getOption('exposed_block')) {

is redundant. We could assume safely that if we are already in a state where the Views itself is re-rendered by Ajax that any associated exposed blocks/forms need to be refreshed too.

By changing that line to

 if ($view->display_handler->usesExposed() && $view->display_handler->getOption('exposed_block')) {

Facets are also attached safely to the block as hidden fields by the search API module and also would allow any other module that depends on any other logic to alter the Block Form and assume that the change will be reflected on the interface.

Any thoughts? Maybe I'm missing the point of that extra GET argument set in

Drupal.views.ajaxView.prototype.attachExposedFormAjax = function ()
...
 // Add exposed_form_display option to the request.
    if (that.element_settings.submit) {
      that.element_settings.submit.exposed_form_display = 1;
    }

Here's an attempt at a 9.5 version of this patch.

Fixed CCF for 9.5.x in #31.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Re-rolled it against 11.x, also applies on 10.1.x.

Was previously tagged for tests which still need to happen.

Re-rolled patch for 10.2.x and added test coverage.

Tests should be added to the MR. But it needs to be cleaned up as there are now a mix of patches and MRs with no explanation or interdiffs between them.

Also issue summary should follow standard issue template.

New patch starting from comment 42 but with adding the missing use.

Error: Class "Drupal\views\Controller\RenderContext" not found in Drupal\views\Controller\ViewAjaxController->ajaxView() (regel 222 van /var/app/web/core/modules/views/src/Controller/ViewAjaxController.php).
Error: Class "Drupal\views\Controller\BubbleableMetadata" not found in Drupal\views\Controller\ViewAjaxController->ajaxView()

There are instances where the form ID can have uniquifying suffix, so here is a change to account for that.
The whole approach looks fragile to me as in theory there can be multiple blocks on the page.
Also I have problem with the facets as the parameter "exposed_form_display" does not get attached, as commented in #28. What is the use case for it?

I've fixed bug with empty "exposed_form_display" mentioned in #45

Noticed bug. when after last the patch the exposed filter block has been refreshed - the exposed form is not submitted by Ajax second time - with page reload.

Update: I've double checked. This is related to custom fixes with views configs or/and temples. Checking what could break this on my test local site.

Yeah, it was bug on my side. The patch works fine!

I've improved a little the exposed form selector to be more precise.

And updated selector in javascript in case if there are multiple exposed forms for the same view on one page

I have tested #49 patch with Core 11.1.1 BEF 7.0.5 and Facets 3.0.0. It fixes the issue with Facets not updating after selecting one.

But it creates another issue in which View Footer and Pagination gets multiplied on every Ajax update. Is there any chance you could have a look at it please?

@david-urban

I didn't notice such bug, but I haven't not tested on Core 11.x yet.
Maybe try to check template for the view. It could be that footer and pagination are outside the view's main 'div' wrapper.
You can check also ViewAjaxController how it replaces content during ajax call so you will have idea what actually is replaced on a page.

I've another one bug https://www.drupal.org/node/3163299 and those patch conflicts with this one in similar lines of code. Have not tried yet though. Trying to compare both patches. I hope those issue's patch will work for all cases.

Update: have just tested patch from the mentioned issue. It doesn't fix problem updating exposed form blocks when selecting filters :(

When using multiple instances of the exposed form block for the same view on one page, both forms are updated but only for one of them the behaviors are attached. Any ideas how to fix that?

When exposed form in block, all attributes including classes are moved from the form to the block. In the latest patch only form is replaced. It can produce some bugs. For example if using better_exposed_filters and exclude text fields from autosubmit, it will not work after ajax replace of the exposed form https://git.drupalcode.org/project/better_exposed_filters/-/blob/7.0.x/j.... So it would be better to replace block and not only form.
So we need to improve somehow this:
$response->addCommand(new ReplaceCommand("form[id^=\"views-exposed-form-$view_id\"]", $this->renderer->render($exposed_form)));

After we updated to Drupal 10.3 and PHP 8.3 this patch caused https://www.drupal.org/project/drupal/issues/3350137#comment-15802025 to occur so I've added back a line to check if the session exists before trying to access it (the session should theoretically always exist so I'm not sure exactly what the problem is).

Turns out the bug I encountered was actually in facets so I'm hiding my patch.

After applying patch #49 i am getting duplicate exposed form on page as i am rendering filters as view block.

Read this thread and #3090504: Views - update filters block on ajax request. Also evaluated current and previous approached in patches and MRs.

Because this issue has found a close-enough solution to cover this issue with tests and there were more activity on that issue, I have closed the other one as duplicate and continue the work here.

Credits should be transferred from the other issue.

Let's start with a clean sheet, I will provide in depth analyzes and details that hopefully justifies my decision.

I have spent hours understanding the root cause of the issue, examining proposed solutions, and analyzing the reasoning behind them. Below I'll respond to previous comments and explain my thought process behind the fix currently pushed to
MR#12048.

The AJAX controller must either replace the exposed form in the block or the block itself. I couldn't find a reliable way to identify and target the parent block(s) containing an exposed form - this also seemed beyond the scope of a controller that rebuilds a form. Therefore, I decided to target and replace the form itself (following @khiminrm's suggestion in #53), and I believe I've resolved the issues he mentioned by removing attributes from the form before replacing it.

@lendude provided crucial information in #12 explaining why the simple approach below doesn't work with multiple blocks and would break when #2894747: Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page is fixed. However, I disagree with #15 that this issue should be blocked by the other one, and I've sought a future-proof solution that will work regardless of which fix lands in Drupal core first.

 $exposed_form_block_render_array = $view->display_handler->viewExposedFormBlocks();
$exposed_form = $this->renderer->render($exposed_form_block_render_array);
$response->addCommand(new ReplaceCommand("[data-drupal-selector={$exposed_form_block_render_array['#id']}] form", $exposed_form));

Since #2894747: Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page will make form IDs dynamic, they cannot be used to target previously rendered forms in blocks for replacement, as new instances will have different IDs than existing ones. While additional CSS classes could be added to forms (like in
the proposed fix for the other issue), finding the right class in an array of classes within the controller seemed fragile. This is why I decided to add a wrapper element around the form and store its ID as a data attribute, which can be easily retrieved and used in the controller.

The solution has been tested with Facets 3.x and Better Exposed Filters, not just with Drupal core's built-in exposed form plugin.

Additional reactions to previous conversations and proposed solutions:

#2 render context wrapping

The Controller always runs within an existing render context - I've verified this multiple times and couldn't find a way to run it outside a render context. Therefore, I don't believe the following workaround is necessary:

+ $context = new RenderContext(); + $exposed_form = $this->renderer->executeInRenderContext($context, function () use ($view) { + return $view->display_handler->viewExposedFormBlocks(); + }); + if (!$context->isEmpty()) { + $bubbleable_metadata = $context->pop(); + BubbleableMetadata::createFromRenderArray($exposed_form) + ->merge($bubbleable_metadata) + ->applyTo($exposed_form); + }

Or the workaround from
\Drupal\views\Plugin\views\style\StylePluginBase::renderFields():

// Views may be rendered both inside and outside a render context: // - HTML views are rendered inside a render context: then we want to // use ::render(), so that attachments and cacheability are bubbled. // - non-HTML views are rendered outside a render context: then we // want to use ::renderInIsolation(), so that no bubbling happens if ($renderer->hasRenderContext()) { $renderer->render($data); } else { $renderer->renderInIsolation($data); }

Due to the existing render context,
->render() bubbles up cacheability metadata out of the box.

Please correct me if I've missed something.

#17 "Add exposed_form_display option to the request." or not

#17 by @allaprishchepa should no longer be relevant since the solution targets the form rather than the block. The block inherits attributes (like the targeted ID selector in #17:
"#views-exposed-form-" . $view_id) when exposed in a block, which may have been the root cause of the problem.

It worth mentioning that I had an interesting adventure/sidetrack where I tried to figure out how to render just the form in a way that it is not exposed inside the block to avoid attributes bubble up from the form to the block, it turned out to be a dead end.

https://drupal.slack.com/archives/C079NQPQUEN/p1746456106393489

Last night I have got an alternative idea that seems even more scoped the task at hand does not introduce any markup change. If this seems better than we probably need a change record to notify contrib/downstream developers that their exposed plugin implementation - unless it extends \Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase must set a new data attribute on the form.

We discussed this issue at Drupal Dev Days (Me/WannesDR/Lendude).

One thing Lendude mentioned is: there are people explicitly using "views exposed forms as block" to ensure their forms are not getting refreshed by AJAX.
To keep this backwards compatible, we suggested introducing a setting to toggle the behavior.
For existing views, the default behavior should stay as is.
For new views, the default behavior can be "update the form with AJAX".

I'd suggest pushing #3163299: Ajax exposed filters not working for multiple instances of the same Views block placed on one page first, which only focuses on replacing the ID and using a data attribute as selector for the AJAX command.

Once that issue lands, we can focus on actually replacing the "views exposed form as a block", keeping the backwards compatibility setting in mind.

To keep this backwards compatible, we suggested introducing a setting to toggle the behavior.
For existing views, the default behavior should stay as is.
For new views, the default behavior can be "update the form with AJAX".

This also occurred to me as a potential BC layer if necessary, so I like the idea, but I am not going to have capacity to work on this right now.

I'd suggest pushing #3163299: Ajax exposed filters not working for multiple instances of the same Views block placed on one page first, w

May I ask why the order matters? Why this one cannot be fixed sooner than the other?
(I am pushing for eliminating the dependency based on the slow progress I have seen on both tickets from the past. However, if both gets active involvement then...)

Wow, I did not want to make these changes, so rolling back. Probably this is needs work due to the previous comment by @strykaizer, but first I would like to have a yey or nay on the proposed solution.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

@mxr576, thanks for closing the duplicate and making a note that the credits still needed to be transferred over. Putting the text in bold is definitely helpful as such messages are easily missed. I'd suggest also adding it as a task in the issue summary "remaining tasks" in the future.

Adding credits for creditable contributions from the duplicate as per #58, and adding a note to the IS that this has been done. Thanks!

The other issue was also classified as a bug and a contrib blocker, which seems correct to me, so marking this as a bug also. Thanks!

While I'm at it, updating the saved credits to credit reviews, substantive patch contributions, etc. and remove credit for simple rerolls or CS fixes according to our presentcore issue credit guidelines. Thanks!

I fixed the problem report by the bot (but I think it checked the wrong MR?).

I believe there still is the unhandled comment from @benroy on the backport MR which also applies to the 11.x MR.

Then there is the open question in #72 and open comments on the 11.x branch. Will leave it at NR for now so it hopefully get's some attention from the correct people as well to help decide on this.

@khiminrm (12 Feb 2025):

When exposed form in block, all attributes including classes are moved from the form to the block.

It looks like custom classes are not output for an exposed form in block, and I created an issue.

I could assume it can be a good solution when only having 1 exposed block with a form on a page, but this doesn't seem to work in case of multiple blocks with exposed filters on the same page.

Use cases when it can be tested: 1) have multiple regular exposed filters on Ajax enabled view, when I want to place them in different regions on the page 2) using Facets 3.0 on the view + exposed regular filters on the same view. For example, I would want to place text search field in one region, and the facets in another region.

For both use cases I would use configurable_views_filter_block module. I will place exposed forms as I want to into 2 separate regions. View has AJAX enabled, assume I use page display (though I tried with both, page and block).

By using $response->addCommand(new ReplaceCommand(...)) approach from proposed patches we'll end up replacing all of the instances of the exposed form on the page. This will lead to duplicated IDs not only on the form, but on its inner fields, too. And this is where the Ajax will break when you try to manipulate filters from different exposed form blocks.

Anyone has any thoughts how to go around that? I couldn't come up with anything since wу are grabbing the form once with $exposed_form_plugin = $view->display_handler->getPlugin('exposed_form'); and we do not know how many instances are on the page

I don't have an answer to your code questions @veronicaseveryn, maybe someone else can help with that?

But I recently tried and failed to update from Facets 2 to 3, after hitting dead ends. I also wanted to place exposed Facet filters into separate regions using the Configurable Views Filter Block module with AJAX, but it seems not possible currently ...

I left a comment in the Facets issue #3354129-5: Update project page with new branch details, trying to summarize the present situation, perhaps some of the issues mentioned are useful? For example, #3509467: Add option to remove (instead of hide) unnecessary filters is about placing exposed Facet filters into separate regions.

Creating and attaching a patch file from https://git.drupalcode.org/project/drupal/-/merge_requests/12048/ so I can use it to test on a site.

We're using :

• Drupal 11.2.4
• Facets 3.0.1
• views_ajax_history 8.x-1.8

Exposed facets filters in a separate block with ajax.

The patch at #88 fixed our use case: an AJAX form with BEFs in a block, and a broken Reset Filters button. Thanks, Finn! +1 RBTC.

I haven't tested this in Drupal 11. But, I tested this MR in Drupal 10: https://git.drupalcode.org/project/drupal/-/merge_requests/12054

The reset button successfully clears the keyword search field, but it does not clear the facet selections.

When using the exposed form multiple times on the same page - for example if you try to use facets 3's way of building a search page -
views.ajax gets added depending on the form id. Using the same id multiple times is invalid HTML, so in order to place the form several times with unique ids and still adding ajax functionality I suggest to use one f the data-attributes to identify the exposed form.
See djanik-3032353-10.5.x-fix-only-backport-patch-da78

Please ignore my suggestion since there is
#3163299: Ajax exposed filters not working for multiple instances of the same Views block placed on one page
which addresses this issue.

Lot of patches and MRs now, not sure what's up for review.

Rebased and fixed phpcs issue but leaving in NW for

Add a deprecation notice to \Drupal\views\Controller\ViewAjaxController::ajaxView() when the new data attribute is not set by the exposed form plugin.

if we are adding a required attribute we probably need an update hook to add to existing views right?

just current MR12051 in patch form to use in composer based build. Verified working on v10.5.4.

@junaidpv, Thank you. I applied patch #96. It is working as expected for the normal input and select fields. However, I faced issues while using the patch along with Tagify module. For the Tagify fields in BEF form, I have to click the Rest button twice to make it work. In the first click, the Tagify fields are cleared. In the second click, Reset button actually works and resets the view. BTW, without AJAX or without form exposed in the block, the Tagify fields are working fine.

Creating and attaching a patch file from #96 for below core & contrib modules.

Drupal 11.3.1
Facets 2.0.10

Exposed facets filters in a separate block with ajax.
Exposed view filters in a separate block with ajax.

It gives several warning messages like these:

Warning: Undefined array key "max" in Drupal\views\Plugin\views\filter\NumericFilter->valueForm() (line 320 of core/modules/views/src/Plugin/views/filter/NumericFilter.php) 
Warning: Undefined array key "min" in Drupal\views\Plugin\views\filter\NumericFilter->valueForm() (line 317 of core/modules/views/src/Plugin/views/filter/NumericFilter.php) 

for date filters in the exposed form.

Calling viewExposedFormBlocks() directly appears to not initializing default values configured for filters. I applied a change in MR12051 to build a block instance and render it to make to go through all regular init processes.

Attached is the updated patch to use in composer scripts.

Seems changes were pushed to 10.5 branch, changes should just be going to 11.x

I'm not able to apply the patch / MR on 11.3. Looks like this needs re-rolling.

I was having some difficulty with git branches for this issue. I've uploaded a patch I managed to make for 11.3.
Looks like the main branch and 11.x have had some major changes.

Just re-rolled patch from #99 for 11.3.x

Just re-rolled for 11.4.0

Problem

I encountered an issue with the re-rolled patch for Drupal 11.4:

• I updated the website from Drupal 11.3.x to 11.4.5.
• I applied the 11.4 patch.
• The exposed forms block no longer updates when AJAX is enabled.

Reason

I tracked down the difference between the output in Drupal 11.3 and 11.4.
It seems that Drupal core no longer pulls the form attributes up to the block
div element. This is probably caused by the following change in
Drupal core: Pull up attributes from
block plugins if the render array has no type or theme on the top level.

Solution

I updated the 11.4 patch with the following changes:

• Removed the code in
  core/modules/views/src/Controller/ViewAjaxController.php that
  removes duplicated attributes from the form, as these attributes are no
  longer duplicated by Drupal core.
• Removed the form selector from the
  ReplaceCommand, as the exposed form identifier alone is
  sufficient to target the element that needs to be replaced.

See the interdiff for the changes.

The patch 115 was causing issues for me, it was removing all filter exposed block classes after loading, and making it not bind the buttons correctly.
Patch 114 is working great with Drupal 11.4.7, and updating the forms as expected.