Hello
Now the sphinxsearch module correctly handles only multi-select and tagged vocabularies. It's because single-valued selects passing their values not as
[terms1] => ( [1] => 1 )
but as
[terms1] => 1
In this case we are validating the form, our sphinxsearch_parse_request() tracts this value as passed from GET (as you remember, our GET contains string values for taxonomies). It tries to load term with name "1" and of course, it fails.
My resolution was to provide a vay to sphinxsearch_parse_request() function to know what it doing right now — parsing GET or validating the form. And to make corresponding handling of the cases. And finally — all sarted to works fine.
Please, review changes. Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | sphinxsearch_taxonomy_handling_.patch | 2.83 KB | neochief |
| sphinxsearch_taxonomy_handling.patch | 2.82 KB | neochief |
Comments
Comment #1
neochief commentedfixed some typos in comments :)
Comment #2
markus_petrux commentedhmm... are you altering the advanced search form? AFAIK, form elements related to taxonomy are built with #multiple attribute enabled in this module, so that's why single-select elements weren't resolved within the request parsing code. So the problem seems to affect also the way the form elements are generated.
I woud like to mention that the way the advanced search form is generated is going to be rewritten with hook_sphinxsearch_api() in mind, and as described here (point 2 below "where do we go?" sentence). It will change because I wish to provide a method to configure which options will be enabled for the advanced search form, and also how those options should be applied to search query filters (AND?, OR?). And that will affect the way form elements are built (single-select vs. multi-select), so it makes sense to code the request parser to differentiate what is generated on submit in each case, etc.
Tha being said, I would not add another argument to sphinxsearch_parse_request(). Maybe extending the information stored in
$request_optionswith an element '#method' that can be set to the value 'post' from the submit handler of the search page (the request parser could then assume 'get' if '#method' is not present).Comment #3
markus_petrux commentedComment #4
neochief commentedYes, I'm altering the form manually, because at this time there are no better way to do needed things. I understand that my changes can be erased by your rewrite, but I have no other way but to write code right now, because of my project's terms. By the way, my series of patches is ending right here, because, it seems that I've complete a working search at my project. So, I just want to thank you, Markus, for the great job you done with this module.
PS. I'll help you fixing the bugs when you'll complete rewriting the API :p
P.P.S. Take a look that I've made
Comment #5
markus_petrux commentedLooks great, and thanks for the compliments.
In the meantime, here's another alternative that will allow you to implement your changes with no need to patch the sphinxsearch_parse_request() function.
Comment #6
neochief commentedActually I've tried to do such thing, but my validator was executed only after sphinxsearch's validator. But with array_unshift trick it can be really possible. Thanks for good idea!
Comment #7
neochief commented