Fix search base path in Facet API adapter

Created on 19 December 2013, over 10 years ago
Updated 8 June 2023, about 1 year ago

There have been a lot of issues and discussions about the retrieval of the base path in the Facet API adapater integration the past. Correctly retrieving the base path is very important for modules like Facet API Pretty Paths, but so far this topic hasn't been completely solved.

First of all, let me explain the current problem, which is caused by the query execution logic:
1. SearchApiQuery::execute() is called
2. This then does $this->preExecute(), which invokes the query alter hook -> search_api_facetapi_search_api_query_alter() -> initialize adapter (and maybe Facet API Pretty Paths requests $adapter->getSearchPath();)
3. Set current search in search_api_current_search();

And as $adapter->getSearchPath(); so far is based on search_api_current_search(), the base path cannot be retrieved as the current query is not yet available. If the current query is not available, $_GET['q'] is used, which is very problematic for Facet API Pretty Paths, as every facet filter is in $_GET['q'].

Unfortunately, to really fix this issue I had to introduce another ugly static function that stores the base path at the time we initialize the adapters and the query information is available. It would be great if we could pass options to the Facet API system when initializing it, but I don't see any possibilities.

Furthermore we should set the option 'search_api_base_path' in any case. This is related to #2088905: Search API Views and Panels paths. β†’ , where the base path is only set for overrides. Instead of manually checking for overrides, I suggest to use Views' API function $view->get_path().
And I think we would have to fix this for the Search API pages module as well (by setting the 'search_api_base_path' option).

πŸ› Bug report
Status

Postponed: needs info

Version

1.0

Component

Facets

Created by

πŸ‡¦πŸ‡ΉAustria mh86

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡¦πŸ‡ΉAustria drunken monkey Vienna, Austria

    OK, thanks a lot! With that, I could complete the described setup. However, the facets look fine to me:

    Have you tried with the latest dev snapshot, now that those get built again?

  • It's been noted that the dev version on the project page was from 5 March 2022 and had since been updated to a build from July. However, I am still seeing a dev version from 2022.

    I was able to clone the git project directly to get this commit, although I had to remove some extraneous code for Views as described in this issue: https://www.drupal.org/project/search_api/issues/3339336#comment-14960583 πŸ› Fix Drush bug when executing all tasks Fixed

    Essentially I had to delete everything from line 731 onwards in search_api.drush.inc

    Anyway, the dev version of the module fixes this issue we were having on a D7 site where facet filters went to the homepage instead of staying on the search page.

  • πŸ‡³πŸ‡±Netherlands ecvandenberg

    I tried to install the latest dev. Altough I do not understand #75 fully I think I run into the same issue.
    Downloading the latest dev with drush does not work.

    $ drush dl search_api-7.x-1.x-dev
    copy(): Filename cannot be empty drush.inc:768                                                           [warning]
    Unable to download search_api to  from .    
    
  • πŸ‡±πŸ‡ΊLuxembourg jean-baptiste

    I applied the solution proposed in #68 on version 1.28 and it also solved the problem for me.

  • πŸ‡³πŸ‡΄Norway steinmb

    @jean-baptiste - Can you tell a little about your config and setup. This issue have proven to be difficult to get verified and commited by the maintainer. We all would love to the fix in an stable release.

Production build 0.69.0 2024