ApacheSolr module integration

Ideally, getSearchPath should return the search path without the facet path segments and be consistent for sites using either apachesolr or Search API

this is the point.

search_api currently has a rather dumb implementation, which leads to getSearchPath including path pretty path segments at the moment

  /**
   * Overrides FacetapiAdapter::getSearchPath().
   */
  public function getSearchPath() {
    $search = $this->getCurrentSearch();
    if ($search && $search[0]->getOption('search_api_base_path')) {
      return $search[0]->getOption('search_api_base_path');
    }
    return $_GET['q'];
  }

how does apachesolr handle this?

i have just pushed changes to calculate basePath and use it.
basically it implements the changes proposed in vrc3's patch.

note: as mentioned here, with the recent update, the required facetapi patch changed! use http://drupal.org/files/facetapi-prettypaths-integration-draft.patch

as always, tested with search_api, please review to see what we need to make this work with the apachesolr module.

the current $basePath approach is "locally" for the pretty paths module, while cpliakas pointed out that, "ideally there should also be a getFacetPath() API method". as i'm currently investigating how to #1431676: Integrate with facetapi current_search module.

currently basePath won't work for pages that are different than the search page.
for example if facets are displayed on the frontpage, they normally link to the associated search page, but the current basePath "override" is not aware of this

should be fixed now, reopen if necessary

i'm reopening as the current implementation is kind of hackish.
described at http://drupal.org/node/1375104#comment-5613602

and cpliakas lists some input in the following comment
http://drupal.org/node/1375104#comment-5615842

i'm using menu_get_item() now to override the base path, if fetchParams finds pretty path segments.

it is still a bit hacky as the url-processor gets fired in many occasions and i have to circumvent facetapi admin pages being processed that way:

    // Skip pretty paths logic for admin pages, as
    // for pretty paths, we have to manipulate $_GET['q].
    // @todo: Fix this workaround?
    if (strpos($_GET['q'], 'admin/') === 0) {
      return $_GET;
    }

regarding apachesolr integration: #1433080: Play nice with the new Facet API Pretty Paths module

i think the described behavior should be fixed already, as fetchParams() now sets the base path.

    // Mock default parameters for facetapi & related search modules.
    if (!empty($params)) {
      // Set search base path.
      $_GET['q'] = $menu_item['path'];
..
    }

but it needs some testing to figure out the details...

vrc3, would you like to try?

(edit) i removed some comments, as i might not have read carefully enough what you mentioned about the apachesolr menu callback

you asked

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?

if resetting the $_GET['q'] in fetchParams isn't enough, we might have to try
http://api.drupal.org/api/drupal/modules%21system%21system.api.php/funct...

i guess so

renaming & waiting for some input

see #1468922: URL aliases require workaround on how to use hook_url_inbound_alter / hook_url_outbound_alter

hook_url_inbound_alter runs before apachesolr & pretty paths, so we could only use it to map a pretty path in a way that it is useable by apachesolr & pretty paths, if necessary.

lets consider an input path like "search/url/segment1/segment2"
an approach might be: map it directly to search/url?q=.... as the fetchParams implementation of the facetapi pretty paths module does

unfortunately, hook_url_inbound_alter runs on every request, while fetchParams does only run when facets are active.

without a clear understanding of how apachesolr vs search_api behave with facetapi regarding the path handling, it seems hard for me to solve this issue.

just to be clear: facetapi_pretty_paths is designed to be generic for any search implementation, but i did only test it with the search_api module.
the above discussion shows, that the apachesolr takes different assumptions and currently it appears just to be broken therefore, though i haven't tested it personally.

i'm willing to review / commit valid patches :)

So, I've been hacking away at this module during Drupal Dev Days in Barcelona and got a proof of concept working.
This is the patch that is required in facetapi_pretty_paths to allow apachesolr + facetapi + pretty paths working.

The magic recipe is that there are also some tweaks needed in Apachesolr but I'll post with a link to that issue as soon as I have written down that issue

Edit : Here is the apachesolr patch #1642140: Make the search query also escape the slash and move away from menu_tail to just 1 argument

hi Nick_vh,

thanks a lot for working on this!

i have just committed a clean way to get the args that sun showed me. that should also work for apachesolr.

what do you think? should we re-roll your patch based on that?

That way of replacing the search path + query is awesome and I'm hitting my head because we weren't able to come up with something like this. However, two other changes still need to be incorporated in the module

+++ b/facetapi_pretty_paths.moduleundefined
@@ -152,8 +152,15 @@ function facetapi_pretty_paths_facetapi_pretty_paths_coders() {
-    if ($facet['field type'] == 'taxonomy_term') {
+    // Check for Apache Solr Taxonomy Term fields
+    if(!empty($facet_info['map options']['module_name']) && $facet_info['map options']['module_name'] == 'Taxonomy') {
       $facet['facetapi pretty paths coder'] = 'taxonomy';
+      continue;
+    }
+    // Check for Search API Taxonomy Term fields
+    if (!empty($facet['field type']) && $facet['field type'] == 'taxonomy_term') {
+      $facet['facetapi pretty paths coder'] = 'taxonomy';
+      continue;

This is still needed to get support for both

+++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy.incundefined
@@ -28,7 +28,8 @@ class FacetApiPrettyPathsCoderTaxonomy extends FacetApiPrettyPathsCoderDefault {
-    $args['value'] = array_pop(explode('-', $args['value']));
+    $exploded = explode('-', $args['value']);
+    $args['value'] = array_pop($exploded);

This should be rerolled and submitted as a different patch

thanks! committed both changes to the 7.x-1.x branch. please tell me if it works for you, so we might be able to roll a new alpha with apachesolr support soon, yeah!

btw the i hadn't used the if continue style within loops that way instead of using select / if elseifs before. interesting

Works perfectly with the following patch #1642140-4: Make the search query also escape the slash and move away from menu_tail to just 1 argument

glad to see that in the end it was that easy to fix :)
thank you