ResourceNotFoundException with ajax facets when site running in subfolder

I've been bitten a few times here as well. What 'fixed' it for me was making sure the path on the search api page did NOT start with a forward slash. A cache clear after save made sure the page worked fine.

I've tried to reproduce this in several ways but am unable to do so. Please provide clear steps to reproduce this based on a clean Drupal installation.

Hi,

We are running into a similar issue.

Our facets (Ajax) are broken when our site is running from a subfolder and we have multiple languages enabled.

Site url example: http://test.test/web/en/search

I did some digging but could not find a direct cause.

I have the same issue with drupal installed in a subfolder and ajax enabled.
Stripping the base path from the $path variable in FacetBlockAjaxController.php resolve the issue for me.

I move the issue to facets project.

i use drupal 8.8.4 and latest dev version of facets.

@swentel
I am facing the same issue, having the website in sub folder. The solution of removing the forward is not working in the views, it adds slash even we save the url without slash.
Any other solution for this.

When i try using the composer this doesn't getting applied. Throws the below error:

Cannot apply patch https://www.drupal.org/files/issues/2020-05-14/facets-3046872-5.patch

This Patch Works for me. When our drupal is installed under subfolder we facing this issue in factes ajax call. Thanks for the Patch.

same patch but for 8.x-1.6

+++ b/src/Controller/FacetBlockAjaxController.php
@@ -116,6 +116,8 @@ class FacetBlockAjaxController extends ControllerBase {
+    $path = str_replace(base_path(), '/', $path);

I wonder if this is safe enough. What if the base path as a string is part of a path alias.
I think that this should be replaced by a regex replace that takes the position into account.

#10 works for my site with a base path.

Re: #13, I agree. However I'd say rather than altering the received `facet_link` value in the controller, the ajax query shouldn't include the Drupal base path in that value. Use drupalSettings.path.currentPath instead. I took a brief look through the javascript and one use case is easy to change (facets-view-ajax.js Drupal.Ajax.prototype.beforeSend function), but the other is some event flow that I'm not familiar with so I can't judge it.

Added patch for 1.8.x

Hi this patch is not working with latest version of Facets 2.0.6.
Uploading a new version.

I've changed the check to use a preg_replace ensuring the base_path() is at the start of the string (a bit safer than just the str_replace).

For version 2.0.6.

#17 fixes the issue for me also. I agree that ajax_query should not include the base path in the first place. But with #3052574: Facets with AJAX not working in most of situations not yet fixed, it's nice to have a minimal solution which does not interfere.

I'm not sure if this was caused by something specific to our multisite setup, #17 didn't work for us.

In our case, base_path() is coming through as '/uk/', and $path is an absolute URL including the host and scheme (https://site.example)

As such, $path does not start with /uk/, so the regex doesn't replace anything.

Uploading a new patch to handle as absolute URLs.

Patch 19 looks like it'll cover more use cases.

Patch #19 also fixed this issue for us for a website living on a subfolder.

Committed, thanks everyone.

patches from guys resolved individual errors, but they did not resolve all cases
for example #17 patch resolves the bug with Ajax facets, but if the page includes a view text filter, it will show the same error as for facets

#19 patch resolves bug with view text filter, but does not handle with facets

so I merged these patches and created MR for it
This will handle all cases

note:
I was able to create MR only for 2.0.x version, there are no other options for now
so currently this MR can not be applied to check 2.0.6 version
I will attach the patch

review for the latest patch (@rollins , please create a new Merge Request for this)

joseph.olstad it looks @borisson_ merged the wrong MR
That MR does not include one of the cases that I wrote on #26
I created a new MR that includes all fixes, also I replaced str_contains with strpos,
because not all websites support this (str_contains only exists in php8)

The MR looks good, it handles one more bug

+1

Added the patch for the MR!180 as it stands now to use in composer.

I created a new MR that includes all fixes, also I replaced str_contains with strpos,
because not all websites support this (str_contains only exists in php8)

Hard disagree. Please use str_contains instead. https://github.com/symfony/polyfill-php80 will ensure everyone can use this.

Safe to say we can rely on php8 + because <= php 7.4 is officially unsupported by current Symfony based Drupals. This module is for D10/D11 not D8.
Therefore, I have no objection to the objection. With that said, I'm ok with strpos. I myself am hooked on strpos but I agree that str_contains is far easier to understand and reads better and it would be great to adopt str_contains.

Currently the biggest issue here is that the pipeline is failing (RED), would appreciate some assistance fixing that.

We ran into this problem after switching from a patched version of 2.0.x-dev at commit 3e6c1ea7 to 2.0.9.

It's an odd issue, as it only seems to happen for anonymous users without any cookies from our site, and only on our (acquia) hosting, not on local dev environments.

MR 180 doesn't seem to have any changes any more.

One thing we will try is catching the ResourceNotFoundException and throwing a NotFoundHttpException - see merge request 242

The other patches we have are for these issues:
#3052574: Facets with AJAX not working in most of situations
#3058314: Facets lost when search term changes, only with ajax

The issue we are seeing is addressed in #3480277: ResourceNotFoundException on 404 pages .

We had originally connected it to better_exposed_filters - see #3396769: Error when added to 404 pages

The change in MR180 was committed during #3467119: Point support > source at project page in composer.json for whatever reason. So this issue is released in 2.0.9. Not sure what to do with the status so I'll put it into RTBC and hope credit is given eventually I guess.

if it is already comitted, I can set this to fixed.