I've added the search results pane to a panel but the results aren't showing. Tracing through it the problem appears to be that the return from apachesolr_search_search_execute(), as executed by ctools_search_result_content_type_render(), specifically that the results are different to what is expected. The code expects the results to be like this:
$results = array(
'#results = array(
0 => // results
1 => // results
2 => // results
),
);
However, when apachesolr_search_search_execute() returns it actually ends up like this:
$results = array(
'search_results' => array(
'#results = array(
0 => // results
1 => // results
2 => // results
),
),
);
As you can see, the array ends up being $results['search_results']['#results'] instead of $results['#results'].
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | ctools-n1343142.patch | 661 bytes | damienmckenna |
Comments
Comment #1
damienmckennaThis patch copies $results['search_results']['#results'] to $results['#results'] so the search_results pane works again.
Comment #2
merlinofchaos commentedOk, this fixes a problem but does not completely fix the problem.
apachesolr also has search suggestions, and this will prevent them from being rendered.
So what's going on here is that normally core returns $build[] with *just* the search results, right at the top. However, apachesolr actually has a search suggestions box which gets them to separate search results from suggestions. This is a great idea, but to support it we really need to improve how we render the search results pane.
So I think what we need to do is search for the 'search_results' -- we can't assume that's where it will be in some other search system and look for whatever has '#theme' => 'search_results' -- that is what we can rely on. If it doesn't exist anywhere, then we can just render what's there.
And we have to figure out what to do about the suggestions because in Panels-land, that's actually a completely separate pane.
Comment #3
merlinofchaos commentedMoving to 'needs work' though I'm going to apply the bandaid anyway because it's better than not having it.
Comment #4
merlinofchaos commentedwebchick suggests that as part of this, we could probably get away with patching core to help this problem and get it into D7 because it is a backward compatible API fix.
My proposal:
Make #title an input to search-result.tpl.php
If it is UNSET (NULL) then we feed it t('Search results') in the preprocess. If it is set we leave it.
Move it to $vars['title'] for the template.
In the template, if it is EMPTY (i.e, FALSE) we don't print the title. If it is not, we print the title.
Anyone willing to work up a patch for core?