FPP lost path context on ajax request

Work for me.

#2 didn’t work for me.
In my ajax view after applying the filter, if I click on the next page, instead of the next filtered page, I see the view without filtering.
I've debugged it a little and found out that q is NULL for url like "?q=/en/products/category/buckets-802&sort_by=created&page=1", from request object I can only get page and sort_by parameters.

I can reproduce #4, it seems that $_REQUEST['view_path'] applies to the originally accessed url.
So if /my-view or /my-view/filter-1 is accessed, it will set this path even after a facet change (e.g. /my-view/filter-2).
If we follow the same principle, we could workaround this by making use of the referer, not sure if this is valid approach though.
I've tested with other query string parameters like full text search or pagination it seems to be fine.

I tried patch #5 and I can confirm that it solves the problem.
Thanks @colorfield

Patch #5 is also working for me... Thanks

Patch #5 is also working for me.

#5 works for me together with the Facets 2.0.x AJAX fix: https://www.drupal.org/project/facets/issues/3052574#comment-15050142

With Drupal 10.1 views is using GET AJAX requests by default, when AJAX is enabled.

In my case we're using views_infinite_scroll and the path context is lost, because of the POST limitation in this commit. I think we would need to make it work with GET requests as well now.

@szeider, if you could kindly share a solution to this, I'll review it.

D10.1-only issue?

Yes, the problem is tied to Drupal 10.1 where the support for AJAX GET requests has been introduced and made the default for example pagination.

It's essentially about this line.

if ($q === NULL && $this->request->isMethod('POST') && !empty($_REQUEST['view_path'])) {

I don't know why the limitation to the method was made, but in my test case changing it to the following resolved the issue

if ($q === NULL && !empty($_REQUEST['view_path'])) {

Thanks @szeidler for mentioning the core changelog and the fix, works for me too. I don't think that removing POST limitation would cause any issue. Here is a patch, it should also apply to 2.0.x branch https://git.drupalcode.org/project/facets_pretty_paths/-/blob/2.0.x/src/...

Removing the `$this->request->isMethod('POST')` check seems like the best approach. We could have checked if `POST or GET request` but I don't see any reason for such limitation.

Tested on one client project and working as expected.

This seems like an important fix.

Would someone be willing to wrap this new condition in a version check?

if (version_compare(\Drupal::VERSION, '10.1', '>=')) {
  // Run the Drupal 10.1+ logic
}
else {
  // Run the original logic.
}

Re done the patch with the additional logic check requested above :)