Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I have a use case where I need to show the same facets on a taxonomy page as on the main search display, and have the term ID from that taxonomy page serve as an initial search segment.
After a lot of Googling, I've found a way of doing it by using a facetapi filter to inject the taxonomy term as a new key. Although it may not be the cleanest approach, it works without pretty paths. Turn pretty paths on, and the pretty path is being generated before the filters are applied - only the new key remains in $build at the end of the filter code.
Is there a way to get pretty paths to process the modified path, or is it back to the drawing board? Generally speaking, should pretty paths only be built after all filters have been processed as filters may modify or alter the number of paths to be built?
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | facetapi_query_override.zip | 2.66 KB | gurrmag |
Comments
Comment #1
dasjoi'm not sure if i understand your exact workflow.
have a look at
hook_url_inbound_alterin #1468922-1: URL aliases require workaround ... does that help?Comment #2
gurrmag CreditAttribution: gurrmag commentedThanks. I'll take a look at that.
As for my workflow, I have a taxonomy page for brands that shows some info on that brand and selected products. However, I want to show search facets on that page to let customers browse deeper. These facets should be limited by the brand being viewed. So if there was a product type facet on this page, the links should be something like: search_path/brand/x/product_type/y. Following various posts, I've got this working without pretty paths by using a hidden facet block view display and writing a custom facetapi filter to add in an extra key to the query to represent the brand being viewed.
This feels like a common use case. Maybe I'm going about it completely the wrong way.
Comment #3
gurrmag CreditAttribution: gurrmag commentedI've had a look, and hook_url_inbound_alter doesn't really help... I don't need to change the URL, but rather I need the links in facets to respect all filters used in a search, even if those filters have been set in a view, rather than in the URL. The post that I found on how to do this by using a facetapi filter will not work with pretty paths because of the order in which things are processed, and perhaps should not be used with facetapi alone as it is overriding the URL on links in facets after it has been built, rather than altering the build process itself.
I've put together something that seems to work for me - I'll tidy it up and see if I can get it into a self-contained module to post back in case anyone else finds it useful. However, this may take some time as it's my first attempt at any real coding and it may not be an appropriate way to go.
Comment #4
gurrmag CreditAttribution: gurrmag commentedI've put together something that seems to work for me...
The attached module uses hook_search_override_query_alter to grab the filters from the search that is being run by the view, and then overrides the fetchParams function from the URL processor to re-write them into the link.
I'm not really a coder so I've re-used as much of the existing URL processor as possible, so that parameters are pulled in from the URL and then any extra ones added. But would there be any reason not to pull all of the filters in from the search query as it would save trying to process them out of the URL as is currently the case?
Comment #5
dasjoglad you found a solution + thanks for sharing!
i think FacetapiUrlProcessorFacetapiQueryOverride shouldn't duplicate that much code from FacetapiUrlProcessorPrettyPaths but i guess most importantly it works for you and others can iterate on it if they have the need to :)