Re-Work get_path() so that the facet blocks can be used outside the search page

Yes - this was on my list to talk to you about. On possibility - a helper function that stores a static boolean (in analogy to the has_searched helper)? Elsewhere, code that knows that we are on a search page could set it to TRUE.

Here ya go.

Why is it important to make sure its this modules search? Isn't enough to do this:

if ($response->facet_counts->facet_fields->$delta)

Not sure what motivates that arg() check specifically, so I took it out. See patch

why $_REQUEST instead of $_GET?

Also, we can probably check if $response is_null(). The if above will throw warnings.

The PHP $_REQUEST variable contains the contents of both $_GET, $_POST, and $_COOKIE.

The PHP $_REQUEST variable can be used to get the result from form data sent with both the GET and POST methods.

Its more comprehensive. The patch does not use that if statement. My question was what motivates :

case 'view':
      if (arg(1) == 'apachesolr_search' && apachesolr_has_searched())

why not just

case 'view':
      if (apachesolr_has_searched())

works for me, and it is what this patch does

we only every care about GET, so there is simply no reasn to use REQUEST.

K fixed and found a path that I missed. The facet blocks work on my custom search page that doesn't use search api. My search page resides at group/ID/search. The facet blocks work fine there. It decouples the arg() logic from the blocks. Still don't know why orginally the apachesolr_search module had this in its block:

case 'view':
      if (arg(1) == 'apachesolr_search' && apachesolr_has_searched())

it was added for a reason, does that reason still exist? This patch removes that if statement as its not apparent to me why it is needed. If that arg() logic is there the uid facet block, for instance, only shows up on the search/apachesolr_search page.

We should either make this a class method, or refactor it into a re-usable function.

Also, you must not be patching against the code at the end of the DRUPAL-6--1 branch. the ->get_query() method no longer exists.

$path = substr($_GET['q'], 0, strpos($_GET['q'], $query->get_query()))

I am using the alpha version, wasn't paying attention to this issue (didn't create it didn't select version). I see its been replaced with

get_query_basic();

is there a

get_query_advance();

Ok this patch is against DRUPAL-6--1.

Notes
1.) In the first hunk I wanted to set the $path = $_GET['q']. But I believe that would include the sort params, which is not what is desired. We want only the keys.
2.) language module had a bug, used get_query instead of get_query_basic. I didn't find an issue for this, but if there is i can reroll with that issues patch

It works well, but I probably should have added some comments around say the first hunk for that first note

Also, the breadcrumbs arn't working. I believe that before this patch they weren't working as before this change and after the $path was exactly the same. If you goto search/apachesolr_search the menu tab isn't highlighted. I believe that is caused by the breadcrumb.

Marked #327833: Allow Override of Core Search Path - /search as duplicate.

This doesn't really make sense to me - we have now totally separated the facet part from the keyword (searrch key) part, so can't we just use $_GET['q'] everywhere unless we are changing the keywords?

Here is an updated patch. The current patch throws errors if you don't have a search query.

Although this seems to be working for me right now, I wonder how well it will if I try to use faceted terms as part of a url callback, for custom search driven nav pages.

I need to display the facets as if i have searched for something on a non search page.

Anyone to point me in the right direction ? Do you do a $response = $solr->search(...) and then call apachesolr_facet_block with the response and initial query?

Any comments appreciated..
Thanks

Poka_dan,

Take a look at the Project module. It has some great code for generating searches for general navigation pages.

Once you get a page callback performing searches, apply the patch in comment # 17, and provide some feedback.

Thanks mikejoconnor,

I managed to do it in my own module by displaying my own blocks and replicating some of the apachesolr_search.module code with some modiffs(where the search query is set and others).

Thanks again.

I've tested this in two sites, and it seems to be working well. It would be nice to have a little more feedback from anyone else using this.

Didn't mean to change the status

With the commit of #254565: Integrate with Views front-end this no patch no longer applies. That commit created a method on Solr_Base_Query called get_path(). This logic now needs to reside there. So its a much smaller patch. I imagine the exact same logic can be applied from this patch in that method.

we could probably do this as part of #432946: Query class and sort cleanups

Re-applied the same logic to the new get_path() method.

I was thinking, perhaps, that the base path would be set when the object is instantiated, rather then here you're doing it repeatedly on demand.

Makes sense... Since using $_GET['q'] at this level does not feels perfectly clean, this new patch also adds a way to explicitly pass on the path. I guess it would be better to use this parameter when possible. I have renamed the $querypath member to $keys to avoid any confusion.

This patch alone is not sufficient to have facet blocks anywhere; it is just an intermediate step.

Kind of feels like $_GET['q'] should not appear anywhere inside the class.

With this patch, the caller of apachesolr_drupal_query() is now responsible for defining the base path. In the case of apachesolr_search.module, it is always 'search/' . arg(1).

looks pretty good at first glance, but will need to test it.

Marked #381076: Base paths in sort/facet blocks as duplicate.

committed to 6.x - do we need any follow-up in terms of the interface definition?

glad to see my substr strpos logic die :-D very cool

Perhaps we'd like get_base_path()/set_base_path() methods?

So, If i'm using 6.1.x-dev, how do I change the search path from 'search/apachesolr_search/xxxx' from 'what-I-want/xxx' ?

From looking at the code, I don't see how this is easily doable. Am I missing something simple?

#327833: Allow Override of Core Search Path - /search was marked as a duplicate, but I don't see how anything done in this thread fixes that issue.

Just found this, #524366: Custom Search Path. It's for 6.2.x-dev, but does seem to map out what needs to change.

I manually applied the changes from #524366: Custom Search Path and got my search url from
'search/apachesolr_search/xxx'
to
'search/what-i-want/xxx'