Ajax facet adds q and _wrapper_format to the browser URL

I guess not too many people have come across this or this would have been re-opened. We're experiencing this issue with the following setup.

Within the platform I'm supporting, CMS Authors can select view, its display, provide optional view argument (contextual filter) using views reference field module, and they can also a Facet Group, a collection facets. The facet group programmatically renders a collection a facets during views render process by implementing hook_views_pre_render(). The views themselves make use of ajax pagination as well as exposed filter with ajax submission.

Also, we've come across an issue where q query param is set even when _wrapper_format is not. The previous logic would only unset both when _wrapper_format is set and is 'drupal_ajax'.

We're experiencing the f query parameter left on the facet URLs. The attached patch remove q and _wrapper_format independently.

I'm setting to Needs Review and referencing #3073444: Create views plugins to render facets and summaries in filters and areas. I suspect rendering facets as filter or summary may encounter similar issues...but unsure.

Aye, the above patch applies the changes after $url->setOption('query', $new_url_params);, and so has no impact on the facet URL. Need to move the logic up before this.

Aye, the above patch applies the changes after $url->setOption('query', $new_url_params);, and so has no impact on the facet URL. Need to move the logic up before this.

Addressed so that $new_url_params is affected prior to being set on $url.

In my case, I have one more parameter which is the ajax_form. I have three steps with ajax request before loading the facets. So maybe that is the reason have this parameter.

It doesn't seem like this should be hacked in php but rather removed from the javascript file entirely. The code adding this is only polluting the query and adding problems. I'm honestly not sure how its not causing more problems.

For example

view_path = "/my_view?arg1=f";
href = "/my_view?arg2=f&_wrapper_format=views_ajax";
views_ajax_settings.url = view_path + '?q=' + href;

suddenly the url looks like this:
/my_view?arg1=f?q=/my_view?arg2=f&_wrapper_format=views_ajax
and Drupal sees the wrapper_format in the wrong place. Also, arg1 is now "f?q=/my_view?arg2=f" instead of "f".

I _assume_ this is some hack that might have helped in d7 and got carried over in the patch but q has no real meaning to d8+ so we can just remove this extra logic.

side note, the wrapper_format part of this was fixed in #3070461: Facet links in modal popup break

For me #8 is working fine

This is pretty straight forward so pushing this RTBC in hopes of getting it moving.

+1 for RTBC

Test again with 2.0.x and Drupal 9.

I think I have a similar problem that is not fixed by this patch.

I have a view with an embed display (so nu URL is set in the view) and when I use the facet it changes the URL's in the facet to /view/ajax? instead of using the original url.

thanks, agree this is RTBC.

Same issue as markwittens.

I am calling the facet block in the view template (via twig tweak) which is a block display

Select first facet filter, url is fine. Select another facet filter, url changes to /views/ajax?f%....

Reloading the page now results in a page not found.

Had to turn off ajax for now which is not ideal.

Patch here seems to address the issue for me

https://www.drupal.org/project/facets/issues/3296120

Updated patch #6 for D10

I attach here another patch for anyone having also applied patch from core issue #2605218: Views Block Display skips preBlockBuild() call on ajax rebuild to remove the extra query parameter "view_query" introduced in that issue.

PS: @roman.haluska your patch contains a foreach loop and immediately after it a if{} condition. Why not everything in the loop?

MR 55 appears to be mergable.

It doesn't appear that a patch is needed for 3.x I can't find where the last patch needs to be applied.

@heddn, the patches, the MR and the whole issue in general targets the 2.x version.
I agree that it's not clear if and what is RTBC; I'd rather set it as "Needs review". From what I understand and remember, MR!55 and patch in #23 are good candidates for committing them.