Posted by robertDouglass on July 4, 2009 at 9:29am
| Project: | Apache Solr Search Integration |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | D6 |
Issue Summary
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()?"
Comments
#1
is this still happening? I think at one point it was setting the page arguments for the menu callback, which was not correct.
#2
In apachesolr_search_view() in 6.x-2.x:
<?php$content = apachesolr_search_search('search', $keys);
?>
means that Solr will be run even at search/node and facets will show up.
Change it to:
<?php$content = module_invoke($type, 'search', 'search', $keys);
?>
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().
#3
#4
Note: not an issue in 7.x
#5
#6
#7
Automatically closed -- issue fixed for 2 weeks with no activity.