It is puzzling to me that q=search/node should call apachesolr_search_view(). This is precisely what happens, though, and one side effect is that the browse blocks in #457826: On empty search, show enabled filters to start a search show up on search/node, with facet link URLs that start with search/node (this can't work, obviously). I think this might be a regression that prevents the proper functioning of the fallback to core search when Solr is unavailable. In any case, we should answer the question, "Is it a bug that q=search/node calls apachesolr_search_view()?"
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 509982.patch | 602 bytes | jpmckinney |
Comments
Comment #1
pwolanin commentedis this still happening? I think at one point it was setting the page arguments for the menu callback, which was not correct.
Comment #2
jpmckinney commentedIn apachesolr_search_view() in 6.x-2.x:
means that Solr will be run even at search/node and facets will show up.
Change it to:
and all is well.
The issue that changed this line is #499302: Remove dependence on search.module.
We will have to do much more to be independent of search.module. I don't mind adding this little bit of dependence back.
This is not a problem in 1.x, which uses search_data().
Comment #3
jpmckinney commentedComment #4
jpmckinney commentedNote: not an issue in 7.x
Comment #5
jpmckinney commentedComment #6
jpmckinney commented