As a comment in apachesolr_facet_block states, at the moment the base path for the facet/sort links are just guessed to be >'search/' . arg(1) . '/'<.

The attached patch implements a better guess, which e.g. also works for apachesolr views, which I'm developing currently.

CommentFileSizeAuthor
#3 apachesolr_block_paths.patch6.5 KBdrunken monkey
#2 apachesolr_block_paths.patch6.45 KBdrunken monkey
apachesolr_block_paths.patch5.46 KBdrunken monkey

Comments

pwolanin’s picture

pwolanin commented

not really sure this is 100% right. I think this will break if there is a slash included in the keywords (which is allowed):

$path_base = substr($_GET['q'], 0, strrpos($_GET['q'], '/')) . '/';

Note that the D6 search module uses: http://api.drupal.org/api/function/menu_tail_to_arg/6

While for D5:

http://api.drupal.org/api/function/search_get_keys/5

However, it' not clear that apachesolrsearch is correctly handing paths with slashes (and no spaces) at the moment.

E.g. this works:

?q=search/apachesolr_search/beer/+solr

this does not:

?q=search/apachesolr_search/beer/solr

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
StatusFileSize
new apachesolr_block_paths.patch6.45 KB

Oh, you're right, that really won't work like this. :-/

Well, next try, this one is based on the fact, that in almost all cases the query will be part of the path, so by truncating the path from the position of the query should produce the path base. Only (?) when arguments would come from a different source, this method would break, in which case no blocks are returned.

OK, one more case in which it would become buggy: If there are other arguments coming after the one for the Solr query. I think this could theoretically be the case in some views. But since those don't work at all at the moment, this patch is still a great improvement.
If I'm right, that is.

Please test!
It seems to work for me.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
StatusFileSize
new apachesolr_block_paths.patch6.5 KB

I came up with another case of failure, which could a bit more common: exposed views filters. Since these arguments don't get passed in $_GET['q'], this method won't work.

It should be relatively straight-forward to implement a way to take care of those: look at $_GET['QUERY_STRING'], explode() twice into an array of arrays containing keys and values, (sort out filters,) search for the keys in the values, then construct the base path and tell the facet blocks how to add the keys to it.

But even if we implement this just as a fallback-solution, it would considerably bloat up the now rather slim algorithm and it's disputable if this would be worth it.

In any case, slightly modified patch since the other produced errors when apachesolr_get_path_base('') was called.

Scott Reynolds’s picture

Scott Reynolds commented

Was able to get it working by using an interface with an updated views implementation

http://drupal.org/node/254565#comment-1427950

David Lesieur’s picture

David Lesieur commented
Status: Needs review » Closed (duplicate)

It looks like this issue has been superseded. The Solr_Base_Query class now has a get_path() method.
And issue #337737: Re-Work get_path() so that the facet blocks can be used outside the search page tries to improve how the base path is set.