🇧🇪Belgium @StryKaizer

You can reproduce this by enabling a module which needs the canonical url, e.g. responsive_preview

What a difficult decision — this is truly an impressive lineup!

- Joris Vercammen (borisson_)
- Montaña Franco (mon_franco)

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 🐛 Ajax exposed filters not working for multiple instances of the same Views block placed on one page Needs work 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.

3163299-views-multiple-ajax-exposed-filters-11.x is a rework of 3163299-views-multiple-ajax-exposed-filters-10.3 which fixes the test and codestyle.

This patch does not include (optional) replacing of the exposed form for e.g. Facets 3.
I'd suggest to keep this patch focussed on replacing the form ID + using a data attribute as selector for AJAX (instead of an ID)
and fix "optionally replace exposed filters in block form" in a follow up.

Good! It looks like this feature only needs tests now.

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.

@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.

underscores issue addressed.
Still needs tests

Hi,

Can you confirm that you are using "facets exposed filters", and that your facets are placed in the Views UI, as exposed filters?
It looks like you are still using the old "facets as block" method, which is not supported for this usecase.

You can find more info on how to use the new Facets 3 workflow overhere: https://project.pages.drupalcode.org/facets/exposed_filters/

+1 for this.

I'd also suggest adding extra info to the form-item "Adhoc email addresses" that these emails gets validated against existing users, if the checkbox from this feature is not checked. This is not clear and for non-tech users this might be difficult to find out :-)

Update hook + config schema added.

Feature pushed in branch. Needs review
For now, works for radios/checkboxes widget and links widget.

strykaizer → made their first commit to this issue’s fork.

@van.dordafog I can not reproduce this problem.

I'm testing on 8.x-1.x HEAD with Drupal 11.
When I change a value from "Dependent filters", it gets saved correctly.

Any ideas how I can reproduce this?

Related issue for Facets: 📌 Support Views Dependent Filters Active

strykaizer → created an issue.

Perfect. Thanks for reporting back!
Closing for now

strykaizer → created an issue.

I can not reproduce this.

To test this I installed a vanilla 11.1.4 Drupal in ddev.
with composer, I installed 1.2 views_dependent_filters
Then I ran composer update drupal/views_dependent_filters -W, which updated to 1.3 as expected.

Can you please document how to reproduce this on a vanilla drupal environment?

strykaizer → changed the visibility of the branch 3512142-facets-3.x-support to hidden.

strykaizer → made their first commit to this issue’s fork.

strykaizer → created an issue.

I just installed this module, and the mapping form works fine for me.

They are indeed empty on install. You'll need to create NotificationProviders defining getTypes, to see items overthere.

strykaizer → created an issue.

This module is currently not working. You need the patch from 🐛 Module uses the wrong selector Active to fix it.

The steps from #2 seem correct, once you have it patched ;)

strykaizer → created an issue.

Features are ready in MR.

Awaiting input for simplytest.me before merging, as it does not show Facets 3.0 as an option at this moment.

strykaizer → created an issue.

Thanks,
I do wonder, why hardcode the options? Wouldnt it make more sense to just use a numberfield, which allows the user to pick whatever they prefer?

Facets summary is not the recommended way anymore since Facets 3.x

For new projects using views + facets, using facets_exposed filters + views filters summary is the actual recommendation, which is documented in https://project.pages.drupalcode.org/facets/exposed_filters/#views-filte...

strykaizer → created an issue.

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

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.

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 work

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.

@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.

strykaizer → created an issue.

A big thanks for all your contributions, Daniel!

People like you are the reason we keep repeating the slogan "Come for the software, stay for the community".

It looks like the best solution would be to have #2205027: VERSION in library declarations does not work for contributed/custom modules → commited in core, so we can cache our assets as best as possible.

strykaizer → created an issue.

Here you go.
Thx for reminding me Pedro!

Added "enable submodule" to documentation now, see https://project.pages.drupalcode.org/facets/exposed_filters/

Not sure why you are not seeing the filter.

Can you try adding a regular filter (not facets), and expose it.
Does that one shows up?

In case you missed this, here is the documentation: https://project.pages.drupalcode.org/facets/exposed_filters/

Thx Frederik!

This is a core issue, patch see 🐛 Views - update filters block on ajax request Needs work

These processors are not supported in facets exposed filters.
This was fixed in 📌 Hide processors which are not supported in facets exposed filters Active

We need to build a views specific solution to support this. This will probably be a non-facets specific module, which will support all views exposed filters (similar to https://www.drupal.org/project/views_dependent_filters → , which does something similar, but not exactly the same).

strykaizer → created an issue.

strykaizer → created an issue.

strykaizer → created an issue.

strykaizer → made their first commit to this issue’s fork.

strykaizer → made their first commit to this issue’s fork.

@edmargomes can you please let me know which exact facets3 version you are using?

Since beta3, I dont think adding this function should matter anymore, and I was thinking about removing that part entirely.

Limitting the options available is exactly what Facets does ;)

You can change the minimum value to 0, but it is probably better to not use facets in most cases, and use regular exposed filters, if you dont want your options to narrow down depending on the selection.

strykaizer → created an issue.

strykaizer → made their first commit to this issue’s fork.

Please open a new issue for this :)

strykaizer → created an issue.

Thanks!

strykaizer → created an issue.

Correct, I encountered this myself when debugging date ranges.

Since query types are now supported since 🐛 Facets Exposed Filters - DateItemProcessor not working Active , the workaround can be deleted, as there's no issue anymore with solr.

Moved to Better Exposed Filters, see #3487805

strykaizer → created an issue.

strykaizer → created an issue.

Core Views renders its "exposed form" before it fires the query.

Because how facets work, we only know the values after the query has been executed.
Thats why we re-render the exposed form again a second time.

That's why, if you are debugging, the first time you'll see an empty #options list, which is re-rendered the second time.

I dont have time to debug the select2 implementation, but this info could help somebody debugging it ;)

For now, "facets exposed filters" uses hardcoded query_type_text.
We need to add querytype plugins support.

Attached is a patch which adds support for different querytypes (e.g. date & range)

This patch breaks showing active facet items with 0 results, as the facet results now act similar to how facet block facet results act.
We probably want to ensure active facet items with 0 items are always visible, both for the old "facet blocks" way, as for "facets exposed filters". This is even more important for "facets exposed filters", as we do not control the url ourself, and views wont remember non-existing elements.