Marry facets and Views exposed filters

Hi mErilainen.

The URL structure is pluggable, so feel free to implement another URL processor such as Facet API Pretty Paths did. Views integration would definitely be nice, and I would love to see some contribution around this since I believe the core module is pluggable enough to achieve the desired use cases. Closing as duplicate of #1274086: Render facet items via views (aka "Views integration") as that should be the issue that Views integration ideas should be posted against. I will cross post to this thread as well.

Thanks for the post and ideas,
Chris

mErilainen,

Ha. I suck at the issue queue. Re-cross posted.

Thanks for picking that up,
Chris

Thanks for the work on this! Can't wait to check it out. Since you are doing some great work and providing some code, re-activating this issue since it would be cool for other people to more easily find what you are doing as well.

Thanks for the contribution!
Chris

Excellent blog post by Wunderkraut on this topic.

This is excellent and much needed, props to the OP for addressing this. Can we roll this as a patch against Facet API dev, I see no reason why it shouldn't be committed... :)

Nice module, Search API is heavy for my shared hosting. Needs to add Dependence in info file.

This is exactly what I need. Three cheers. I have not tried it out yet but will today. Thanks!

Are the values of the facets always filled in the views exposed filters? Do you really need to use the Wunderkraut module when you want to display a fulltext search box and the "results per page" dropdown on your Search API Views page? Is that the only way to let them work together? Is it correct that you need to include all your facets into your views and hide them with CSS then?

Maybe this will help someone: http://drupal.org/sandbox/Soul88/1865682

I think the root of the problem here that seach index have only one facet adapter so Only One url_processor allowed.
So if you need some kind of "mixed" sources to set active facets so you need a lot of work to attach url_processor with some kind of context-data.

Some simple example: display 2 views from one search index on page with different filters/facets but this require to reset statics(facetapi_adapter_load) and hack into hook_facetapi_searcher_info() to conditionally set processors

Was looking for similar solution - it would be great, if url structure between exposed filters and faceted search could be unified to get both for the same view.
Perhaps a separate views sub-module could be a solution, like BEF?

Forgive me if this the wrong arena for this. I am new to both Search API and Facet API.
I am building a directory site which needed both a way to search by a listing name and display results with taxonomy. facets for further filtering, and I needed taxonomy links on the homepage that would show listings with those facets active.

My solution, which may be absolutely demented, I dont know was this:
Search index with 2 facets for my relevant taxonomies.
A search api view, to list all relevant fields. On this view An exposed search filter as a block.
A view on my homepage that lists my taxonomy name, with tid as hidden field.
I rewrite the taxonomy name field as a link, prefixing with the path to the search view, the facet result path, and passing the term name and tid so it matches the url pattern of an active facet.
I used facet pretty paths to make this easier on me.

I set the block to appear on all pages.

This seems to work fine.

Is this a sensible way to achieve this, or am I missing something vital here?

I've started to combine the approach provided by @mErilainen and @Soul88.
The attached patch contains a dedicated module which will be located in facetapi/contrib/views.

Features:

• Configure the url processor per searcher.
• Added a dedicated views filter handler that adds the current facets to the exposed form.

Not yet tested with Facet API pretty paths or similar modules.

Awesome idea and clean approach!

@andypost I'm not really happy about the form field injection in the views handler. But it was the only way I could think of how I can use facetapi_get_active_searchers() to get the searcher of the actual view too. Another possibility would be to load all searchers but that could bring quite some overhead.

Is this supposed to work with text exposed filters like search_api_views_fulltext?

After applying the patch I still cannot make exposed filters work with facets (Facet api + search api views).

EDIT:Finally it works without using the previous patch.

I tested the patch in #26 and had some issues with it - it did not work for single-value facets/exposed filters. I'm attaching an updated patch that fixed the issue for me along with an interdiff file with the changes I made compared with #26.

There's an issue in the patches from #26 where non-facet query string parameters were not being persisted when selecting/deselecting facets. I've resolved that in the attached patch and am also including an interdiff file from #25.

I applied the patch from #27 but the facet string in the url is of type f[0]=field__fuel_type_%3A1
Am I missing something?

Has anyone any luck with this patch?

Any news on this? :)

Hello,

it seems that patch work with only one facet active. When i have 2 facets or more, as multiple facets have the position "0" inside they proper facets, we lost some of them when merging parameter inside "f".

Removing the $pos during the fetchParams() seems to fix that, but i'm still not sure of all the implication.

To me this is a great candidate for a separate contributed module. Would love to see this as it's own project, and would be happy to link to it on the project page. That way it can continue to innovate at it's own pace and get the attention that it deserves.

Works great, but the problem is when user select option "Any" in Views exposed filter and there is no results when there should be all results displayed. Any known solution for this?

I am also experiencing what #33 reports. Is there a known work around?

What about if the facet has taxonomy hierarchy?
#33 didn't work for me...

Any news on this?

Respectfully marking as won't fix.

This is a great idea and some good code, but as mentioned in #32 it would be best for this to be it's own contributed module so that it can innovate and improve at it's own pace.

Thanks for all the work on this issue and I look forward to linking on the project page!
Chris

This is great stuff that works well for me. So i did some Improvement on it and added it as full project.

https://www.drupal.org/project/facetapi_views

Any one like to join as co-maintainer - go PM me!

A link on the project page is appreciated.

Just added mErilainen as comaintainer. Welcome aboard!

I'm excited to see that this being worked on. Thank you! Here are a few URL persist sandbox modules that may help that were created for similar fixes.

VEFKUP - views exposed filters keep URL params
Persist url params

Nice work ! but it's breaking my pretty alias feature with "Reuse term aliases"

Really like the direction facetapi_views is taking, this (at first glance) seems to address the problem raised in this ticket. I'm curious however, if it makes sense to roll a separate module for this feature. I think most people are going to use Facet API in the context of views, and making the facets themselves play nicely with Views features seems to be a high priority. Is there any way of rolling the work being done on facetapi_views into the core facetapi module (or adding it as a contrib module inside facetapi) so that people don't have to go and look for a separate solution?

Again, thank you to axel.rutz and team for the hard work here! Looking forward to a release of the facetapi_views module.

BTW there's a patch in #2378945: Facets are lost by Views on keyword search for Search API that resolves this problem automagically :)

@damien #43:
> ...that resolves this problem automagically :)

would this obsolete (parts of) this module?

I haven't tested the module, the code solved the problem I had.

Hi, Is this succeeded now for Drupal 7 please?
Thanks for sharing the answer, greetings Martijn