I have multiple Search API indexes and use Views for the search pages. All of the searches use exactly the same current search block, which perfectly worked in version 7.x-1.0.

After upgrading to 1.1, the current search block is only visible on one concrete search and invisible on the others. Maybe this was a side effect of #1668980: Current Search block appears on all pages when there are two search blocks?

Comments

cpliakas’s picture

Hi mh86.

Thanks for the post.

I have multiple Search API indexes and use Views for the search pages. All of the searches use exactly the same current search block, which perfectly worked in version 7.x-1.0.

Although this worked for your use case, to me this actually seems like a bug. In order to prevent unexpected behavior, a current search block has to be tied to a single "searcher". I am not sure how Search API works with views, meaning that I am not sure if the searcher will be different for the different Views.

If you can help me by providing a really simple use case that I can replicate on a clean install of Drupal, I will work with you to debug this issue and find a working solution to this problem.

Thanks!
Chris

mh86’s picture

Status: Active » Postponed (maintainer needs more info)

Thanks for the quick reply!

Actually I think it's very cool to just have one current search block and to re-use it for all of your searches. We do that e.g. in the Recruiter distribution, where we have a job and a resume search and both have the same current search block. Are there potential problems with that?

And, while testing this use case with the Recruiter distribution another time, it started to work again (maybe it was an additional cache clear). The weird thing is that it is still broken on a more complex site. Anyway, I have to do more testing and will let you know what I can find out.

cpliakas’s picture

Hm. Interesting. Thanks for posting back!

The only issue I can see is that if there are two active "searchers" on the same page, then the current search block will get confused and not know which one to use. Therefore there is the restriction to tie the current search block to one searcher. I'm not sure how this relates to your specific setup, but I wanted to give some background on why the limitation is coded as is.

Chris

mh86’s picture

Did some more debugging:

  • current_search_check_visibility() is used for checking the block visibility, which then calls current_search_get_block_searcher() and in my case uses current_search_get_default_searcher() for determining the current search (takes the first one). The search api default searches are then retrieved via search_api_facetapi_facetapi_searcher_info() which does an search_api_index_load_multiple() (entity load multiple).
  • On my Recruiter installation the order of the seach api indexes (search_api_index_load_multiple) changes based on the views search page, and the first one is always the correct one. I guess the according index is loaded before and then statically cached, leading to the correct order.
  • On my other installation I use page manager pages with embedded views content panes. For that the order stays the same on every page and thus only works for one index

As the current search block has a setting for the search page, the fact that I can reuse it due to a strange entity load order thing is more a bug than the other way round.

Still, I think it would good to allow reusing current search blocks, e.g. have a setting that allows a multiple selection, or a 'visible on all searches except..". Usually most current search blocks on your site should behave the same way.

Not sure which category this issue falls into: bug report or feature request? :-)

mh86’s picture

and one more thing: it was the update from rc4 to 1.1 that showed me this problem. I think the relevant change was between rc4 and 1.0.

cpliakas’s picture

Title: Missing current search block for mutliple search api searches » Allow the current search blocks to be used by multiple searchers
Category: bug » feature
Status: Postponed (maintainer needs more info) » Active

Thanks for the excellent debugging! Let's go with a feature request, because as mentioned above, this is working as designed to prevent possible conflicts. I am willing to work through this, and you definitely have a common use case I am sure others are looking to solve as well.

Again, great work,
Chris

flyke’s picture

Issue summary: View changes

Just for people who stumble upon this (old) page like me when they search on how to have more than one index, each with a 'current search' block:

If you need a second 'current search' block for a second index, you can just clone the existing current search block via admin/config/search/current_search. Then edit your clone for the desired second search index.