In core views filters I can add a filter in the UI, be presented with a list of vocabularies and then get a list of terms to select form. When the filter is exposed I can select and autocomplete or dropdown list. In a search api index based view I only have the numeric filter.
I have had a look around the code. I've gotten as far as adding a new data type for taxonomy term but then I'm stuck. When I select my new data type in the UI ("Term"), the views filter UI reports a broken handler like this
id: packaging
table: search_api_index_fof_product_index
field: packaging
plugin_id: search_api_numeric| Comment | File | Size | Author |
|---|---|---|---|
| #3 | taxonomy_views_filter-2650100-3.patch | 1.13 KB | stborchert |
Comments
Comment #2
drunken monkeyThere is already a filter plugin for taxonomy term fields,
SearchApiTerm. However, I just checked and it seems that that doesn't get correctly added as the plugin used for those fields, so that's just a bug. Apart from that, this functionality should already be there.Comment #3
stborchertI found this issue while searching for a solution for a very strange error I got adding a term name as an exposed filter to a search view (btw.: its better to use the term Id as filter but that didn't work either).
Don't know if the patch is a complete solution but adding this made the filter work.
Comment #4
borisson_@stBorchert: Would it be difficult to add a regression test for this issue? I'd love to see a red test for this so it's easier to understand what exactly is wrong.
Comment #5
stborchertHm I'm not sure about this, but I think, we need to create an entitytype like paragraphs without a canonical link and try to index this. I'm not at home at the moment and will have a look onto it on monday.
Comment #6
drunken monkeyThat seems like #2596385: No link template 'canonical' found for the 'paragraph' entity type, not this issue?
For this issue, we should just add a term reference field to a content type, index it and then see whether our Views data contains the correct filter plugin (
search_api_term) for that field. (And, maybe, while we're at it, also test whether the plugin works as expected. But that's a different issue, in the end.)Anyways, your fix doesn't seem correct to me. If there really is a problem, it seems like either
_search_api_views_get_handlers()doesn't compute the right$typesfor that field (it should containentity:taxonomy_termfirst), or_search_api_views_handler_mapping()for some reason doesn't contain a mapping for that type (which would be strange, but could of course still be the case – it's a bug, after all, which already means something is going wrong).Your code more looks like it would add that filter plugin also for properties of taxonomy terms, if I'm reading the code correctly – which wouldn't be what we want.
Are you maybe trying to place a filter on something like
field_tags:name– i.e., not the reference itself, but the reference name? Then that's supposed to use the normal handler for strings, not for taxonomy term references, that's "works as designed" – index and filter on the reference itself to get the term-specific handler.Comment #7
stborchertOh, looks like I've mixed up two issues in my answer.
And yes, we indexed the name-attribute of the term. I will try to use the reference and test if this works.
Comment #8
drunken monkeyAny news on that? Is it fixed?
Comment #9
stborchertUsing the term directly in the index did the trick for filters. Unfortunately term fields are not added as arguments.
Comment #10
drunken monkeyYes, I think argument handlers aren't done yet, sorry.
However, it seems this issue here is resolved then?
Comment #11
stborchertFor me, its resolved. I am working right now on the argument handler and try to find an easy solution :)
Comment #12
drunken monkey