A module has been created very recently to give faceted search links built by the Facet API pretty paths instead of query strings. Take a look at Facet API Pretty Paths.

Currently, apachesolr seems to grab everything after the path to the search page as the search key, which lumps the facet pretty path into the search key. So if I do a search for "chicken", and then facet by "garlic", the pretty path looks something like "/ingredients/garlic-2348". This means that the search key used by apachesolr will change from "chicken" to "chicken/ingredients/garlic-2348". Clearly, this is not wanted.

What is the best solution for this? Is it possible to use some kind of menu alter hook from within the Facet API Pretty Paths module? Or is a change to apachesolr necessary?

I have temporarily added a line to a few functions in apachesolr that grabs only the first argument in the path after the path to the search page. This will break search queries that contain "/". I think it's likely that this is unavoidable. Either way, my gut says that this isn't the best solution.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

pwolanin’s picture

this is probably just going to be closed as "by design"

The custom pages functionality already lets you pre-filter content based on a path component.

vrc3’s picture

this is probably just going to be closed as "by design"

The custom pages functionality already lets you pre-filter content based on a path component.

Is it possible to use that feature to make facet api pretty paths work with apachesolr? Can you explain how?

Or is there a way to use some kind of menu alter hook from within the facet api pretty paths module to fix this?

Because without some kind of solution to this issue, whether it happens in apachesolr or in facet api pretty paths, there will be no way to make pretty paths for facets work with apachesolr.

pwolanin’s picture

Status: Active » Closed (works as designed)

I don't know. You could probably make it work for one specific facet, but not for all facets.

dasjo’s picture

added some comments regarding this at http://drupal.org/node/1434462#comment-5632300

vrc3’s picture

Any insight into which functions can be overridden or which menu alter hook could be implemented in the pretty paths module to make this work?

wwhurley’s picture

Issue summary: View changes
Status: Closed (works as designed) » Needs review
FileSize
1.35 KB

Sorry to re-open this, but this is an issue. Attached is a patch that pulls the query parameter from the FacetAPI url processor. The standard one uses $_GET and the FacetAPI Pretty Paths one pulls the facet path parts out so both work correctly.

Status: Needs review » Needs work

The last submitted patch, 6: 1433080-apachesolr_pages_facet_params.patch, failed testing.

wwhurley’s picture

Version: 7.x-1.0-beta16 » 7.x-1.x-dev
FileSize
1.17 KB

Re-rolled patch with correct path.

Nick_vh’s picture

Status: Needs work » Needs review

Let's test this

Status: Needs review » Needs work

The last submitted patch, 8: apachesolr_search_pretty_paths-1433080-8-D7.patch, failed testing.

Nick_vh’s picture

Status: Needs work » Needs review
FileSize
1.65 KB

Status: Needs review » Needs work

The last submitted patch, 11: 1433080-11.patch, failed testing.

Nick_vh’s picture

Tested this and it seems to be working well. I'm a little scared that for the keywords we now depend on facetapi but from what I've seen there is no negative impact.
The only thing that I can see that could impact it is other modules adding stuff to the url. Because of this and the late stage of the project I'd feel inclined to add another statement there and only invoke this when facetapi_pretty_paths is enabled.

Maybe we even need a hook where context and facetapi_pretty paths can hook into, eg : hook_apachesolr_search_page_pre_alter($page_id, $keys, $path_replacer);
It would allow for a cleaner apachesolr_search_custom_page and the implementation could be in facetapi_pretty_paths?

Interested in hearing what you think!

wwhurley’s picture

The more generic probably the better. I can always propose a patch for that project, too.

dasjo’s picture

sounds good to me

kopeboy’s picture

I just tried pretty paths and it doesn't work on latest stable releases of both modules.
When I disable pretty paths apache solr works like expected, but enabling it brakes everything. The noticeable thing is the breadcrumb, when working (without Pretty Paths) shows the search filters I applied, when not working (with pretty paths) they become Search > Site > Site > filter.