On a Search API index view, I have an "addressfield" (via the Address Field module) and normal field api fields. Some Addressfields with "Selective" work, and others don't.
For example, if I add "Locality (Selective)", it works, but not when I add "Country (Selective)". The following error message is shown:
Fatal error: Call to protected method SearchApiViewsHandlerFilterOptions::get_value_options() from context 'views_handler_filter_selective' in /var/aegir/platforms/panopoly-7.x-1.25/sites/hub/modules/views_selective_filters/views_handler_filter_selective.inc on line 487
I can't say what is the culprit in this case, since other fields within the Search API indexed view work without issues, and other Addressfields within the view work as well.
Thanks in advanced for your help.
Comment | File | Size | Author |
---|---|---|---|
#16 | views_selective_filters-2548881-16.patch | 4.46 KB | bmcclure |
#15 | views_filters_selective-search_api_support-2548881-15.patch | 6.62 KB | ccjjmartin |
Comments
Comment #2
david_garcia CreditAttribution: david_garcia commentedComment #3
NWOM CreditAttribution: NWOM commentedOh thanks. Hadn't realized it was a feature request.
Comment #4
Alex Bukach CreditAttribution: Alex Bukach commentedBasically that method is not guaranteed to be public, so that the module should check whether it can call it (see the patch attached). On the other side, for Search API to work with the module that method should be public on Search API side (see the patch at https://www.drupal.org/node/2352853).
Comment #6
david_garcia CreditAttribution: david_garcia commentedCommited.
Thanks for the patch.
Comment #7
Alex Bukach CreditAttribution: Alex Bukach commentedJust to make it clear, this patch was worth applying (since just existing of a method doesn't mean this method is callable), however it doesn't fix the original issue.
Unfortunately I have to state that Views Selective Filters module is generally not compatible with Search API Views in its current form, and it is compatible only with views making SQL request (since Search API Views can make e.g. Solr requests instead etc. depending on Search API server type).
Comment #8
david_garcia CreditAttribution: david_garcia commentedGiven that the module is internally relying on cloning the original view I can't see why it cannot be made on anything that works as a view such as Search API. That is why I built it that way to prevent dependency on anything behind Views. Probably someome with time/budget can make it work withou too much hassle.
But yes the patch was worth applying :)
Comment #9
Alex Bukach CreditAttribution: Alex Bukach commentedDavid, the problem is that
class SearchApiViewsHandlerFilter extends views_handler_filter
, andclass views_handler_filter_selective extends views_handler_filter_in_operator
. In its turnviews_handler_filter_in_operator
class relies on SQL, in particular on using$this->query->add_where()
method which is not available forSearchApiViewsHandlerFilter
. Therefore attempt ofviews_handler_filter_in_operator
class to call that method onSearchApiViewsHandlerFilter
throws an error. To fix it we should either addadd_where()
method to all Search API query classes, or makeviews_handler_filter_in_operator
extend genericviews_handler_filter
class and implement all methods without any proposal about view storage engine.By previous comment I meant that the fact that the module doesn't work with Search API views is not a bug, the module is not intended to work with Search API as it is now.
Comment #10
NWOM CreditAttribution: NWOM commentedShould we set this back to "Active" then, since the original feature request has not been committed?
Comment #11
geek-merlinAlthough this might not be easy, it's a reasonable feature request.
Comment #12
pierostz CreditAttribution: pierostz commentedHello guys,
I am jumping in just to clarify things for others and me.
As I can understand Search API and Views Selective Filters are not working together. So a feature request was opened and no changes were committed yet but is this discussion a workaround? Meaning.
To get this to work we need two patches
1. The patch provided here for the Views Selective Filter.
2. And this patch for the Search API part.
Am I reading through correctly?
Comment #13
david_garcia CreditAttribution: david_garcia commentedWrong. To get this to work, you need to someone to properly work on it and then share.
From #7
Considering that we build on top of the Views abstraction layer, unless someone comes with a specific issue - such as underlying storage not supporting aggregation -, I can't see why this won't work with the Search API.
Comment #14
pierostz CreditAttribution: pierostz commentedThanks for the quick reply david_garsia.
Please excuse my ignorance on the subject but can you elaborate on this one.
My situation is not like the issue at hand. It's much simpler. I have a Search API index and with that I index taxonomy terms. In my view I am populating a field with those terms and then I create a selective filter based on that field. The selective filter comes empty.
Based on your statement above such a simple scenario works or not? If it's not working is this a bug or a feature? And also If is a bug or a feature do I open another issue?
Thanks
Comment #15
ccjjmartin CreditAttribution: ccjjmartin at Four Kitchens commentedThrowing up a patch that solved this issue for my exact needs:
1) Patch is based off version 1.5
2) Allows integration with taxonomy terms and search api
If those are your only needs then you can probably apply the patch and it will start working.
I am putting up an incomplete patch because I almost gave up at some point through this because of the issue previously mentioned about the
add_where()
method missing. This patch still needs:1) Further testing to verify it doesn't break existing views selective filters
2) To remove the reliance on the selective filter being tied to taxonomy terms (left a @todo code comment)
3) A possible refactor to replace most of this with a new views handler and some code in views_data_alter
Hope this gives the next person to come across this a jump start.
Comment #16
bmcclure CreditAttribution: bmcclure as a volunteer and at Top Floor commentedHere is a slight refactor and reroll against the latest dev of the last patch. I think it addresses item (2) from the list in the last comment in being more generic.
However, it still doesn't work for me, because I think that this assumes the field being loaded is on the main entity in the search index, when in fact it could be on a related entity of a different type. I'm not sure if that's the only issue or not, but I figured I would post an updated version of the last patch in case it helps anyone else in the meantime.