When using the group-specific search or people search, the appropriate ApacheSolr query string isn't added and the search isn't refined.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 1471816-commons-apachesolr-search-8.patch | 5.09 KB | ezra-g |
| #5 | 1471816-commons-apachesolr-search-4.patch | 2.53 KB | ezra-g |
| #4 | 1471816-commons-apachesolr-search-3.patch | 2.04 KB | ezra-g |
| #2 | 1471816-commons-apachesolr-search-2.patch | 1.75 KB | ezra-g |
| #1 | 1471816-commons-apachesolr-search.patch | 1.7 KB | ezra-g |
Comments
Comment #1
ezra-g commentedIt's not clear to me if this feature worked previously.
I tested this patch with a local ApacheSolr setup.
In general I'm not clear on when
case 'type':would come into effect and I feel like this code has the potential to be refactored for increased readability.This patch also corrects a call to menu_get_item() which had an unnecessary parameter.
Comment #2
ezra-g commentedI couldn't handle the $group = NULL;
I've moved further nitpicks into #1472226: commons_core_form_search_theme_form_alter() nitpicks.
Comment #3
ezra-g commentedThose are both the wrong patches from the ones I tested and meant to upload.
Correct patch coming after this short caffeine break ;).
Comment #4
ezra-g commentedComment #5
ezra-g commentedAs it turns out, B) from #1472226: commons_core_form_search_theme_form_alter() nitpicks is necessary in some cases to make sure that apachesolr_search doesn't override the submit handler for the search_theme_form().
Comment #6
ezra-g commentedWhen no group is specified, the site falls back to core search.
Comment #7
ezra-g commentedTagging for triage for the 2.6 release.
Comment #8
ezra-g commentedComment #9
ezra-g commentedFollowing some additional testing, #8 is committed. http://drupalcode.org/project/commons.git/commit/87d3810ad9b849eeb6ae13c...