🇧🇪Belgium @StryKaizer

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

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

Fixed in 2.x and 3.x

This has been reworked since beta3. There is no url processor anymore for exposed filters. It uses native views.

Thanks,

I adjusted this a bit to use defineOptions instead, which allows us to set a default value globally, and I added 2 extra variables which also needed a default value.

Thanks @anybody

Ic, I assume you are placing your "exposed filters" in a block in that case?
Thanks for debugging, I'll fix this asap!

While I dont mind committing the above, I'd rather find out why this value is null.
Anyone having this issue who could debug?

I can't reproduce this myself.

Does this happen on existing views + facets exposed filters only? Or also on newly created views + facets exposed filters?

Hmm, interesting.
You would need to debug this in getActiveFacetValues() in modules/facets_exposed_filters/src/Plugin/views/filter/FacetsFilter.php

I wonder why this function returns NULL in your case.

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

I was able to reproduce this when ajax is enabled.

Attached is a quickfix.
Please let me know if this fixes your issue.

@anybody: are you using 3.x-beta3?