I have a Searchapi Solr view with a view context display. I also have a panels page that uses that view as a context. Maybe I'm doing this wrong, but I did this so that I could have a page that includes my search results and facets in custom panels layout.
Everything seems to work except the Current Search block always shows even when I have "Display when either keywords are entered one or more facet items are active." selected.
I was hoping to only show that block if someone clicked on a facet or entered a search keyword.
Any ideas on how to hide it?
Thank you for making such a cool module!
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1992228-5--current_search_block_with_empty_keys.patch | 972 bytes | drunken monkey |
Comments
Comment #1
cpliakas commentedHi gmclelland.
Thanks for the details and the kind words.
Looking through the Search API adapter (the class the interacts with Facet API) there is something interesting in the getSearchKeys() method. Specifically, line 181 says "Work-around since Facet API won't show the "Current search" block without keys.". To me this implies that Current Search Blocks's check for keywords always passes with Search API. This might be a red herring, but it seems like a good place to start debugging.
Thanks,
Chris
Comment #2
gmclelland commentedI appreciate you looking into this. I think this would probably be over my head coding wise. Just a note: I'm using search_api_solr 1.0-rc2 and search_api 1.4 because Pantheon doesn't yet support search_api_solr 1.0-rc4. I guess it is a possibility that it might work with newer versions of the modules.
Do you think this issue should be moved to the Search_api queue?
Comment #3
cpliakas commentedNeither does Acquia :-) #1977510: Acquia Search for Search API is incompatible with Search API Solr search 7.x-1.0-rc4. It was a pretty massive, albeit positive, API change between RC3 and RC4. So search_api_solr RC2 is perfectly fine.
I'm not sure, to be honest. If the code I pointed out does seem to be the source of the issue then it would make sense to move to the Search API queue. I am also happy to keep it here until more debugging info is added. I personally don't use Search API, so I am asking for the community's help in digging deeper.
Comment #4
gmclelland commentedMoving this issue over to the search_api folks to get their input on the comment in #1.
Comment #5
drunken monkeyAh, sorry, I didn't realize you added that option. In this case, we of course don't need that workaround anymore. Attached is a patch that would remove it.
I still think that "Display on empty searches where no keywords are entered." should be the default, though. Otherwise, I think a lot of users will wonder where their current search blocks went.
Comment #6
cpliakas commented@drunken monkey,
Thanks for the patch! My bad for not vetting Search API with the addition of this change. Regarding the default setting, it was made that way based on feedback from people who were confused as to why it was showing up on empty searches due to what it displays by default, but I would definitely be willing to have a discussion about that at Facet API to come up with a sane default based on what search administrators expect.
Thanks again,
Chris
Comment #7
gmclelland commentedThanks @drunken monkey - After trying the patch here is what is happening:
I have the current search block set the following:
Display when either keywords are entered one or more facet items are active.
- When I initially view the page without keywords or facets active, the current search block is not shown - Yay!
- When I click a facet becomes active, the current search block is shown - Yay!
- When I enter keywords into the search, the current search block is Not shown - :(
So close
Comment #8
drunken monkeyAre you using the "Search: Fulltext search" filter for adding keywords?
Comment #9
gmclelland commentedMy apologies, I had mistakenly exposed the title instead of the "Search: Fulltext search." After making the change everything is working correctly. - Yay!
Comment #10
drunken monkeyGreat, thanks for testing!
Committed.