Inside of apachesolr_search_search is some code that gets values from the $_GET and arg(1) which makes it hard to override those values.

I'm trying to have search respond at the URL of "example.com/explore/keywords here" and in my callback I do:

  $results = search_data($keys, $type); 

Later on, though, the code gets upset at:

        $results = apachesolr_search_execute($keys, $filters, $solrsort, 'search/'. arg(1), $page); 

I could change my URL to be "explore/apachesolr_search" but that is ugly. I could use url_rewrite_inbound/outbound, but that's also ugly/painful/not-performance helpful.

So, I changed apachesolr_search.module to read:

        $results = apachesolr_search_execute($keys, $filters, $solrsort, 'search/apachesolr_search', $page); 

And that works fine. I guess an alternative is to just call apachesolr_search_execute directly. Is that the better solution to this problem?

Comments

greggles’s picture

Another example of this problem is in the fact blocks. When you use them on a url other than search/apachesolr_search they point to the wrong address.

I know I could rebuild those myself - just curious whether that is the "right way" to do it or we should make solr work in more places.

jpmckinney’s picture

Assigned: Unassigned » jpmckinney
jpmckinney’s picture

Category: bug » feature

Support for custom URLs is a feature.

jpmckinney’s picture

Assigned: jpmckinney » Unassigned
drupalninja99’s picture

same deal...changing the solr url is really annoying

pwolanin’s picture

Status: Active » Closed (won't fix)

not adding to 6.x at this point

greggles’s picture

Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Closed (won't fix) » Active

Is this not relevant for 7.x branch?

jpmckinney’s picture

Status: Active » Fixed

There is significantly less hardcoding in 7.x and it is much easier to do there.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.