Hi guys,
I have a filter set up which has a text search box. It is tagged with fs-cmsfilter-field=name, and it works great. I also am using the URL querystring feature, so when that filter is set name=whatever appears on the querystring,
Here’s the important bit, we use that querystring to initialize the filter from other pages. e.g. ?name=foo needs to initialize the name filter with foo.
Here’s where that breaks.
Yesterday the client needed to expand the text filter so that it filters on multiple fields, e.g. fs-cms-filter-field=name,email,address. With this setup, I see the querystring still show ?name=, however the inbound matching route stops working.
What’s the right way to do this? It’s relatively important that it be consistent too, because these types of filter querystring links will go out in emails etc. and need to work even if the client adds another field into that filter set.
Hey @memetican! You could use the * identifier for your text filter, the only issue is that this would show as *=foo in the query.
The * identifier targets all filter fields available on your CMS Items
Thanks a ton Luis, that’s a good approach in this case. Unfortunately it required some script to support their sitewide-nav-based search box, because you cannot set an input element’s name to *. The resulting querystring on a GET submit becomes field=...
It would be nice to have some better control over CMS Filter’s querystring interface to solidify that “contract” for calls from other pages, QR codes, email newsletter links…
Are there any API hooks where I can intercept that “deserialize the querystring” step, and help CMS Filter digest the results appropriately? Seems like that would require a serialize step as well.
I’m afraid not at the moment for the CMS Filter API. The best bet would be custom code added to the solution
1 Like