Support exposed filters rendered in a block

Hi @strykaizer, thanks for creating this issue.

Could you give more details about your problem and how to reproduce it?

@mably sure

Render your exposed form as a block.

Click a filter

Try to remove the filter in the summary. (It will not work)

Pull request added.

That's exactly how I would have done it 👍

A reason for changing the selector format when querying the document?

At this moment, exposed form ids are not unique, if you render them in a block and place the block twice.
There's an open issue for that, see 🐛 Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page Needs review

However, your suggestion would work too, as getElementById always returns the first match, which would work fine.
I kept the context search, as I think its a bit cleaner to first scan in context only (less dom crawling, not sure if that gives performance boost though). But you can remove that if you prefer so.

Sorry, I didnt respond to your question

"A reason for changing the selector format when querying the document?"

No, no reason for that, I don't even understand how that happened :)
Gonna blame Github Co-pilot for that. Ofcourse it should be the same as the context selector.

Ok, I can see that the patch associated with the above Views issues uses Html::getUniqueId that adds a suffix to the form ID to make it unique.

Now I understand the fix suggested here: https://www.drupal.org/project/views_filters_summary/issues/3490316 ✨ Filter removal issue with multiple exposed forms + AJAX Active

May be we could add it to this issue's MR?

What do you think @strykaizer ?

Not sure.

That patch probably will break the current implementation anyway, as it looks like views_filters_summary expects following #id

'views-exposed-form-' . $this->view->id() . '-' . $this->view->current_display

. I'd probably just watch that issue, and once it gets committed, test and adjust :)

Maybe in the future, you'll need to use another selector instead of the exposed form id, (e.g. data-exposed-form-views-filter-summary="view_id__view_display"), which you add yourself in an hook_exposed_form_alter

Ok, thanks a lot for your feedback @strykaizer, let's merge as is.

Actually the Views issue patch add the standard name as a class of the form:

+    $clean_form_id = Html::cleanCssIdentifier('views_exposed_form-' . $view->storage->id() . '-' . $display['id']);
+    $form['#attributes']['class'][] = $clean_form_id;
+    // The form can be possibly rendered twice on a page, make the id unique.
+    $form['#id'] = Html::getUniqueId($clean_form_id);

So we could use the CSS class in the query selector if we don't find the form using the id.

Fix included in new 3.0.0-beta2 → release.

Automatically closed - issue fixed for 2 weeks with no activity.