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).

CommentFileSizeAuthor
#74 term_url_alias_correct_facet_link.png72.64 KBdrunken monkey
#72 example-views-export.txt15.46 KBecvandenberg
#72 example-views-export.txt15.46 KBecvandenberg
#58 2159827-58-facet_paths.patch533 byteskarlshea
#35 2159827-35--facet_paths.patch1.38 KBdrunken monkey
#35 2159827-35--facet_paths--interdiff.txt785 bytesdrunken monkey
#31 2159827-31--facet-paths-fallback.patch657 bytes.bert
#30 image (4).png29.26 KBsysdoc
#26 2159827-26--facet_paths.patch758 bytesdrunken monkey
#25 view-block-url.png74.84 KBhubbs
#17 search_api--patched.tar_.gz14.15 KBdrunken monkey
#15 2159827-15--facets_search_base_path.patch3.4 KBdrunken monkey
search_api_facetapi_adapter_base_path.patch3.36 KBmh86

Comments

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

If it finally fixes this mess, I could live with one additional static global …
However, to make sure that that's really the case, I'd need a few reviews from people who were previously affected by these issues.
Please try to get reviews from some of the participants here:
#1861786: Fix base path issues
#1827272: Facet path can be incorrectly returned
#1863866: Make sure base path is set correctly for search api views

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

No-one want to review here? It would be really great if we could find a solution that works for everyone (everyone not relying on broken code, of course).

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

as maintainer of https://drupal.org/project/facetapi_pretty_paths would be great to get some feedback from site builders so we can resolve #1861786: Fix base path issues

kopeboy’s picture

kopeboy
Primary language Italian
Location Milan
commented

I think most of website builders will find this too advanced/complicated. I guess you guys should test the patches you submit first and we can trust you to include them! If anyone making a new site will find problems for sure he will come here and provide a comment or a new issue.

My problem for example is that OR facet filters don't work, but I don't know if its related to this cause I don't understand what you are talking about.

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

there are many ways to build searches using search api in drupal. as a module developer, it would be helpful for me to get reports from site builders on their approaches and what solution works for them. you are right, this is a tricky issue, at least there are some solutions proposed, now we'd need people test them

kopeboy’s picture

kopeboy
Primary language Italian
Location Milan
commented

Ok, I can and will test and review this... but what is the problem this patch should solve ?!
Is this patch still relevant if I'm using Pretty Paths DEV?

Currently, my problems with Searches are:

- Facets not working with Panels (so for example I had to create 15 different Views, which list the same contents but start with a fixed filter - the main category filter - to be able to set proper , i.e. different, metatags for each main-category-search-page.

- Facets not working with OR filter. Example: I am listing business by category, geografical area, and specific services. The user who wants to find a business will always want to use the OR filter between the facets values because the services are additive and the geografical areas are mutually exclusive.

- Multiselect module not working with pretty paths enabled
-> then I would like to enable pretty paths ONLY on some filters/facets, in order to use it normally on non-multiselect filters, and still use multiselect (with Chosen) for a facet with many many options (i.e. geografichal areas)

Just in case, this is the error I get when I try to filter by more than one value on an OR facet:

An error occurred while trying to search with Solr: "400" Status: Bad Request: Bad Request<html><head><title>Apache Tomcat/7.0.42 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 400 - null</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>null</u></p><p><b>description</b> <u>The request sent by the client was syntactically incorrect.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.42</h3></body></html>.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

In a nutshell, it tries to fix all the problems related to facets linking to wrong paths. So if you have any problem that a facet creates a wrong path, please try the patch.
Otherwise, however, it would probably still be good to get reviews from people to see if the patch breaks anything. So even if you have no problems in that area, it would be good if you could check that the patch doesn't introduce any for you.

girideepa queued search_api_facetapi_adapter_base_path.patch for re-testing.

mvdve’s picture

mvdve commented

Tested the patch and is doesn't seem to work.

My use case:
I use panels everywhere, an exposed fulltext search block and facet blocks on the same page. The base path of the corresponding view page is not set when the search block is used, so no results. The current page is used and the get variables are added to the path (like a facet block). The facet blocks work fine.

When the panel everywhere panel is disabled, everything works.

With the patch:
The search block - current page path is used
The facet blocks - the base path is empty so http://domain.com/?f[0]=....

Small edit:
- I think my situation is not really a facet api problem, more fulltext search block related. So not sure if it fit's this issue.

mvdve’s picture

mvdve commented

I did some further testing and something funny is going on:
There was a error introduced in my dev setup. I didn't had a search page but a search panel pane. This will not work because there is no path defined and search api will only look at the path of the view.

Now the results with the patch applied:
- When a facet block is used - the base path is the path of de view (in my case /search).
- When the fulltext search blok is used - The get Q variable is used (current page).

So both values are switched.

Unfortunately I have no time to do further at this moment but i will resume on Monday morning.

jantoine’s picture

jantoine commented

This patch worked well for me in multiple instances. The first instance was with a panel page that had several views panes placed in it where the views panes were holding search results. Configuring the views panes so that the path could be overridden and then overriding the path in the views pane when placed in the panel page allowed me to specify the correct search path.

The second instance was with a panel page that has a Facets Block placed in it. In this case the 'Search page path' was not being respected and the path was defaulting to the path of the first page display found within the view. I wrote a patch in #2169909: Facet API blocks only working correctly with view's page display that uses a similar approach to ctools for overriding a views path.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

So it seems after over two years we have two votes in favor and one against? That's really pitifully little to go by.
No-one else affected by problems with Pretty Paths and up for giving this patch a test?
(Or even just willing to verify this doesn't break their working site – having a few people verify that would also be great already.)

mvdve’s picture

mvdve commented

The patch does not work in my setup. As described above: or the search path is not correct, or the facet path is not correct.
In the end i used a dirty solution by adding the base path in a hook_form_alter for the search box. I will try to find some time to do more testing this week.

jandewit6’s picture

jandewit6 commented

Struggling with the same issue in getting a facet filter to direct to the base pasth instead of adding on to View path.
Am using pretty-path as well.

Is this patch still relevant for testing in Search Api 7.x-1.20?

If so, please let me know and I am happy to patch, test and provide feedback.

If not, please let me know which alternative path I would need to follow.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
StatusFileSize
new 2159827-15--facets_search_base_path.patch3.4 KB

Seems the patch in the OP doesn't apply anymore, here is a re-roll.

But apart from that, as far as I know the patch is still relevant and we're still trying to figure out if it resolves the problems, or at least solves some and doesn't break anything. If you could test it on your site and report back, that would be great!

jandewit6’s picture

jandewit6 commented

Auch, getting error messages in the patch.
I am not a particular regular patcher, so chances are good that I go wrong somewhere.
Could you otherwise send a patched module or set of patched files, then I do the testing foodwork.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
StatusFileSize
new search_api--patched.tar_.gz14.15 KB

Here you go!

jandewit6’s picture

jandewit6 commented

Hi,

Sorry for taking so long. Busy here and coudn't get my head to it.

Tried, and get this:
Fatal error: Cannot redeclare search_api_facetapi_menu() (previously declared in */public_html/sites/all/modules/search_api/contrib/search_api_facetapi/search_api_facetapi.module:14) in */public_html/sites/all/modules/search_api/contrib/search_api_facetapi/plugins/facetapi/adapter.inc on line 362

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

Sorry, but that's completely inexplicable to me. You've apparently done something wrong. Please first download a fresh (dev) version of this module, and then (inside the "search_api" directory) unpack the archive attached in #17.

farse’s picture

farse commented

I have used this patch to fix a facetapi pretty paths issue and it is working well for me!
My comment is here https://www.drupal.org/project/facetapi_pretty_paths/issues/1981578#comm...

  • drunken monkey committed e5baa86 on 7.x-1.x authored by mh86 
    Issue #2159827 by mh86, drunken monkey, farse: Fixed wrong search base...

drunken monkey credited mh86.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Needs review » Fixed

Awesome, very good to hear, thanks a lot for your feedback!
Committed.
Thanks again, everyone – especially Matthias, of course, for the initial patch (seven and a half years ago …)!

hubbs’s picture

hubbs commented

FYI, this patch broke my search.

I have 4 facet blocks with a `Search page path` set. After updating the Search API module, clicking a facet was bringing me to my site homepage because the url was returning like

/?f%5B0%5D=field_topic%253Aname%3ACompany

Instead of

/resources?f%5B0%5D=field_topic%253Aname%3ACompany

Reverting this patch back fixed the issue for me.

hubbs’s picture

hubbs commented
Issue summary: View changes
StatusFileSize
new view-block-url.png74.84 KB

Forgot to post a screencapture for clarity.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Fixed » Needs review
StatusFileSize
new 2159827-26--facet_paths.patch758 bytes

Well, shoot. Predictable, really, as every other attempt so far has also failed, but still disappointing.
Thanks for reporting this so quickly, though!

In your case, it seems like we just set an empty path, which of course never sounds like a good idea. So, maybe the attached patch is already enough to fix this?
Would be great to get many testers here (especially if things are working fine for you with the unpatched 7.28 release), to ensure this really improves things, and doesn’t break it again for others!

I also added a mention of this in the release notes – hopefully we’ll get a few more testers that way.

sysdoc’s picture

sysdoc commented

I faced this problem too. Contextual filters are not replaced in patch and remain %

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
sysdoc’s picture

sysdoc commented

This does not solve the problem and is not connected with it in any way.
I have no problem with version 7.x-1.26

sysdoc’s picture

sysdoc commented
StatusFileSize
new image (4).png29.26 KB

I have no problem with version 7.x-1.27
Only with version 1.28

.bert’s picture

.bert commented
StatusFileSize
new 2159827-31--facet-paths-fallback.patch657 bytes

The patch in #26 does not solve the problem in our case.

We're using the Search API Pages module and it appears there's no way to tell the system of the search path, so our facet links are all populated with a blank slug, as described in #24.

Enabling FacetAPI Pretty Paths for the index solves the problem for us in a different way and allows the URL to be rendered properly, but doesn't really fix the issue here.

I wonder would it be good to add the $_GET['q']; back into the search_api_facet module as a fallback? This was removed in the last update, though there was probably good reason.

Would the attached patch work? This can be applied independent of the patch in #26.

It may make more sense to update the Search API Pages module for this use case.

.bert’s picture

.bert commented

Oh, and to add to the patch in #26, it worked without issue in our environment for the facets in our other search views. No regressions.

ramil g’s picture

ramil g commented
Status: Needs review » Reviewed & tested by the community

.bert's patch in #31 seems like a good patch for this. We have tested it and it works. Changing the status to RTBC.
Thanks @.bert!

ekes’s picture

ekes commented

Would be great to get many testers here (especially if things are working fine for you with the unpatched 7.28 release), to ensure this really improves things, and doesn’t break it again for others!

7.x-1.28 upgrade: facets on the search page itself working, the facets that were used on the frontpage (which isn't the search page, but used to link directly into it) broke. The facet blocks in both cases are place in panels (yep so the search page has the search view as a panel pane too, not a page with a path). Was working - no memory of how it was set up. Upgrade just broke front page facets as mention. Patch on #26 fixed this.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new 2159827-35--facet_paths--interdiff.txt785 bytes
new 2159827-35--facet_paths.patch1.38 KB

Thanks a lot for everyone’s feedback, and to .bert for the new patch!

I don’t think we ever want to set the value saved in $path in search_api_facetapi_current_search_path() to the current path. That should just be set via the search query.
Instead, we should make it just a fallback return value for the function.

Also, let’s combine the code of both our patches. Hopefully, that should resolve this problem for the most people. (Thanks in this context again to .bert, for clarifying that #26 didn’t cause any regressions, either, if it didn’t help with the new problem.)
Please help by testing/reviewing again, then I can commit it.

And sorry for causing this problem in the first place! In hindsight it seems pretty clear how that broke facets in cases where the search_api_base_path query option wasn’t set. (Though this should probably be fixed, at least for Search API Pages, anyways: see #3230680: Add the "search_api_base_path" option to search queries.)

kevinsiji’s picture

kevinsiji commented
Status: Needs review » Reviewed & tested by the community

Tested with success.

alex72rm’s picture

alex72rm commented

Hi everyone,

I'm very sorry, but the patch in #35 (the latest) doesn't work to me.
I've contextual filters that are missing in the URL when I try to follow URLs from defined facets, that bring to a "page not found".

No issues with previous releases of Search API.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

Great to hear, thanks for the feedback!
Anyone else? The more people test now, the lower the chances that we break something with this yet again.

Edit: Oops, cross-posted with Alex72RM. The above is just the reply to kevinsiji.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Reviewed & tested by the community » Needs work

@ Alex72RM: Thanks for your feedback, too, although it is less great to hear. ;) (But, of course, all the more important!)
So you have no problems with version 7.x-1.28, but as soon as you apply the patch (and maybe clear the cache) the facet links are wrong – is that correct? If so, I really have no idea what could cause this …
Can you share what the URLs look like before and after applying the patch? And, potentially, details about your view’s setup?
Do you also have problems with the patches in #26 or #31 (or combined), or just with the latest one?

.bert’s picture

.bert commented

We're using the patch in #35 in production now on about 30 properties with various configurations and it's working without issue. Thanks again for the continued support, @drunken monkey!

For @Alex72RM: What do you mean by "contextual filters"? Are these the filters from the Facets or additional filters in the view? Are you using the Facet API Pretty Paths module?

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

@ Alex72RM: Would be really great to get more feedback from you on this, otherwise I guess I’ll have to just commit the patch as-is (which seems to resolve the problem for a lot of people) and wait for the next issue report.

alex72rm’s picture

alex72rm commented

@drunken-monkey: I've applied the #35 patch at the latest -dev (1st sep 2021).

A link to a facet search becomes (it's in Italian):

http://<base path>/rilasci-da-pta?f%5B0%5D=field_capitolo%3AInvestimento%20%20%20%20%20%20%20%20

the name of the view is "rilasci-da-pta".

With the previous version (1.27) the path is:

http://<base path>/rilasci-da-pta/2021-01-01/1?f%5B0%5D=field_capitolo%3AInvestimento%20%20%20%20%20%20%20%20

where "2021-01-01" and "1" are contextual filters that come from the related view.

With the latest version (-dev) with (or without) patch, the contextual filters are missing from the path. That brokes the URL link.

The cache is emptied and I don't use Facet API Pretty Paths.

Hope this can help.

steinmb’s picture

steinmb commented

Also broke our search facets - Broken facet search https://elmcip.net/search

Config

Search               Database search (search_api_db)           Module  Enabled        7.x-1.8
Search               Search API (search_api)                   Module  Enabled        7.x-1.28
Search               Search Facets (search_api_facetapi)       Module  Enabled        7.x-1.28
Search               Search pages (search_api_page)            Module  Enabled        7.x-1.5
Search               Search Views (search_api_views)           Module  Enabled        7.x-1.28
Search               Solr search (search_api_solr)             Module  Enabled        7.x-1.15
Search Toolkit       Current Search Blocks (current_search)    Module  Enabled        7.x-1.6
Search Toolkit       Facet API (facetapi)                      Module  Enabled        7.x-1.6

Applying patch #35 fixed it in test (yet to roll it to prod.

steinmb’s picture

steinmb commented

@drunken-monkey sorry, had to roll #35 in prod.

#42 we do filtering on dates though only year and for us it seems to be working https://elmcip.net/search/games?f%5B0%5D=type%3Awork&f%5B1%5D=field_work... though I have not done a lot of testing.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

@ Alex72RM: How about the latest dev version without the patch? Does that work correctly?
If it’s also broken there, I guess we can at least commit this patch for everyone else’s benefit and then try to figure out why it doesn’t help in your case.
Have you tried disabling caching? (Just to check whether that’s part of the problem, of course, not as the permanent solution.)
Or is it an AJAX view, maybe?

alex72rm’s picture

alex72rm commented

@drunken-monkey:
Hi, I had already used the latest -dev without the patch, but without the desired result. For me, no problem committing the version. I'm staying with 1.27. To answer your question, the view cache is disabled and it was not ajax enabled to update it.

steinmb’s picture

steinmb commented

What version of the Date module are you sitting on? I have for the last year been trying to help out moving that module forward and I have seen problems like example #3206821: Date pop up widget breaks exposed views form with Error : Cannot create references to/from string offsets etc. popping up in the issue queue

alex72rm’s picture

alex72rm commented

@steinmb:
I was using the "date" module version 2.10, so I immediately upgraded to 2.12. Then I tried again to update search_api to the latest -dev, cleared the cache and checked if the behavior changed. Unfortunately not: contextual filters (they are two indexed fields, year and version) disappear in the URL, while they are correctly present with search_api version 1.27.

steinmb’s picture

steinmb commented

Oh well. It was worth a try :) - Your site, is the default language Italian? Any active interface or content translation eabled?

Care to share with us what search related modules you have, example: drush pml | grep search

alex72rm’s picture

alex72rm commented

Ok, if you need to understand how to solve the problem which is very strange just because everything works well with the previous version of search_api. I am attaching the list of search modules I have on the website. The site is in Italian, activated and default. I don't use localization modules. 

Database search 1.8
Search 7.82
Search API 1.27
Search API autocomplete 1.7
Search Facets 1.27
Search ranges 1.5+14-dev
Search Views 1.27
SearchIndex Wipe 1.1
Solr Search 1.15
jean-baptiste’s picture

jean-baptiste commented

Hi

I have the same problem with 1.28: contextual filter disappear from the URL, thus leading to a 404 page when selecting a filter but ...
it doesn't happen with the "Range: min/max UI slider" widget.

i.e. widget with "Links" or "Links with checkboxes" -> error.
Change widget to "Range: min/max UI slider" -> works fine.

I tried patch #35 and dev version (both or only dev or only patch): no success.

For the moment I've downgraded to 1.27 which works fine.

todd zebert’s picture

todd zebert commented

This also broke our facet "Links" items, by removing the path portion of the URL, while the query portion was fine.

Reverted to 1.17.

steinmb’s picture

steinmb commented

@Todd Zebert Did you test latest dev and/or patch in #35?

jbiechele’s picture

jbiechele commented

This is just to confirm that fix #35 solved my disappeared search path after upgrading to search_api 7.x-1.28.
Thank you for the patch.

jrb’s picture

jrb
he/him
Primary language English
Location Raleigh-Durham Area, NC, USA
commented

The patch in #35 fixed the missing-search-path issue for us.

  • drunken monkey committed 318fac5 on 7.x-1.x authored by .bert 
    Issue #2159827 by .bert, drunken monkey: Fixed regression with wrong...
drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Needs work » Active

Well, seems that this patch still isn’t prefect, but at least fixes the problem for a lot of (or even most?) people, while not breaking the behavior for anyone (as far as I can see).
So: committed.
Thanks again, everyone!

@ Alex72RM (and everyone else still experiencing problems with the latest dev version): Would it be possible for you to debug the return value of search_api_facetapi_current_search_path() both in 1.27 (supposing it works there) and the latest dev version?

(I’m leaving this open so any subsequent patches will hopefully tested by a lot of people, to make sure we don’t introduce any regressions yet again.)

karlshea’s picture

karlshea
he/him
Primary language English
Location Minneapolis 🇺🇸
commented
Related issues: +#3259231: Facets use the wrong URL
StatusFileSize
new 2159827-58-facet_paths.patch533 bytes

Facets are using the wrong path when the view has contextual filters. For example, I have a view with the path "/by-price/%' and the argument is for a term name.

in query.inc both the original code and this code are using $this->view->get_path(), which returns /by-price/%. It seems to me (and works for me locally) that it should be calling $this->view->get_url(), which includes the current contextual argument (e.g. /by-price/5).

Patch attached, but I'm not sure if this is re-breaking something that was discussed above.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Active » Needs review

Thanks for this suggestion. I could indeed reproduce your problem and verify that your patch resolves it. However, I’m clearly very hesitant at this point to commit any patch for this, especially with such a change that I’d have thought someone else would have noticed before. So, would be great if others could test this patch, too, and report back whether it breaks anything for them, or maybe even fixes a view with contextual filters where they didn’t even notice that facets weren’t working properly.

ecvandenberg’s picture

ecvandenberg commented

I tested patch #58.
First tried to apply it to search_api-7.x-1.28 but that did not fit.
Then applied it to the latest dev and that worked.

The issue I had is solved by this patch. I used a view for taxonomy pages with a contextual filter.

rudy.barrett’s picture

rudy.barrett commented

I confirmed patch #58 works in my environment and fixed the issue.
As said in #60 you must install search_api dev first - composer require 'drupal/search_api:1.x-dev'

I also had to re-index my solr indexes but after that the facets worked correctly.

Side Note - I didn't have search_api dev installed first and the patch failed to install and stopped my composer script from running, I had to drush re-enable search_api, search_api_views, and search_api_facetapi as a result once I installed search_api dev and patched.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

Sounding good so far. Anyone else? The more feedback, the better.

And yes, please make sure to use the latest dev version. As a rule, patches are only created against the latest version.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Needs review » Active

OK, it’s been over two months and 100% of testers report the patch working, so let’s commit this. We’ll leave this open anyways, again, so people can report it if this broke anything for them (again). Very much like Whac-A-Mole, this whole issue.

steinmb’s picture

steinmb commented

Ref #64: +1 to that plan :)

When do you plan to tag next stable 7.x release?

alex72rm’s picture

alex72rm commented

I fully agree with #61. Now it works all great!

steinmb’s picture

steinmb commented

@druken monkey: For some reason is the dev. version did not get rebuilt with the latest commit. It is still the Mars 5 build on the project page. I think it would be easier to get feedback and more end user tests if it was updated.

ecvandenberg’s picture

ecvandenberg commented

I wanted to try the latest dev again to check it would solve this issue. But like #67 noted, the patch is not included.

Patch #58 does not fit on the latest stable version as well as on the latest dev version.

I'm not set up to create patches but what I did was changing the file manually.

/sites/all/modules/search_api/contrib/search_api_views/includes/query.inc
Line 323 of both version 7.x-1.28 and the latest dev.

Changed:

$this->query->setOption('search_api_base_path', $this->view->get_path());

to

$this->query->setOption('search_api_base_path', $this->view->get_url());

It solves the issue and I don't see any negative side effects.

ecvandenberg’s picture

ecvandenberg commented

...as often happens when I just click around happily ... I do see some negative side affect of #68.

When the taxonomy term has an alias, that does not apply anymore after using facet filters.

As an example. When you have a view and use a facet filter the URL should becomes something like this

/term-name-alias?f[0]=field_filter:28

With #68 applied the URL will be:

/taxonomy/term/32?f[0]=field_filter:28

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

Unfortunately, I have no control over when/whether the dev snapshot tarball gets rebuilt. It should happen regularly, when there are new commits, but if it doesn’t, you should create an issue for d.o itself, probably in the Infrastructure issue queue.
But good to see it now seems to have resolved itself, with a July build that should contain this new commit.

@ ecvandenberg: Bugger. Any idea how to resolve this?

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

@ ecvandenberg: Could you please provide an export of the search view you’re using? I already fail at the basic setup you describe.

ecvandenberg’s picture

ecvandenberg commented
StatusFileSize
new example-views-export.txt15.46 KB
new example-views-export.txt15.46 KB

Thanks for getting back on this one...

A reduced version of my view is attached.

ecvandenberg’s picture

ecvandenberg commented
drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented
Status: Active » Postponed (maintainer needs more info)
StatusFileSize
new term_url_alias_correct_facet_link.png72.64 KB

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?

caesius’s picture

caesius commented

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

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.

ecvandenberg’s picture

ecvandenberg commented

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 .
jean-baptiste’s picture

jean-baptiste commented

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

steinmb’s picture

steinmb commented

@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.

benstallings’s picture

benstallings commented
Status: Postponed (maintainer needs more info) » Closed (outdated)

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.