Block facets don't apply contextual filters on ajax response

Works for our site

Thanks for the patch. It worked.

I think this should be added to the module ASAP

Let's start by putting this issue to needs review, so that the testbot can have a look.

+++ b/src/Plugin/facets/facet_source/SearchApiDisplay.php
@@ -162,9 +162,22 @@ class SearchApiDisplay extends FacetSourcePluginBase implements SearchApiFacetSo
+      // Check if request is from ajax
+      $ajax_request = Request::createFromGlobals();

This does not check if this is an ajax-request, so either the comment is not valid, or the code isn't, in any case this is confusing.

+++ b/js/facets-views-ajax.js
@@ -95,11 +95,11 @@
-  var updateFacetsBlocks = function (href) {
+  var updateFacetsBlocks = function (href, views_arguments) {

Is this a BC break?

Thanks for the patch. It worked.
I think this should be added to the module ASAP

You seem to be on drupal.org long enough to know this is not how that works. This issue is still in active, and we haven't seen what tests break with this patch. At the very least this issue should be moved to rtbc, before we add it to the module.

@ccx105 PS: It seems you (like many others – it's really easy to misinterpret) are confused by the "Issue tags" field. As the guidelines state, they aren't meant for free text tags related to the issue, but only for specific categorization purposes, usually by module maintainers. They are certainly not intended to tag with the module name in the module queue.
So, if you aren't sure your current usage is correct, please just leave the field empty.

Back to needs work for remarks in #10.

I faced the same problem.
We have a lot of patches for the Facets module, including custom patches (that are not from DO).
So I had to update the patch from #5 and create a new one.

Also, I had to add a patch for ViewsBlock.php because it doesn't include arguments from block configuration.
And we also have a lot of patches for Drupal core, so I'm not sure that it can be relevant for anybody.

In addition to the concerns in #10 the patch in #6 works when selecting filters but does not work when other exposed forms are changed (e.g. exposed sort forms) because updateFacetsBlocks is also called in Drupal.Ajax.prototype.beforeSend and not updated there to add the view arguments. Seems like getting the args there might be a bit dicey...

It seems like it might be preferable to handle the arguments in Drupal.behaviors.facetsViewsAjax and maybe add them to settings.facets_views_ajax? That way they could be accessed by updateFacetsBlocks (or any other function) without having to pass parameters around or determine DOM/View IDs again.

Attaching a patch here with a different approach -- getting the request data in \Drupal\facets\Plugin\facets\facet_source\SearchApiDisplay seemed a bit off to me so instead this patch attempts to achieve the same result but from \Drupal\facets\Controller\FacetBlockAjaxController::ajaxFacetBlockView (the controller called by updateFacetsBlocks in facets-views-ajax.js. My approach is to:

1. Find and add relevant View settings (including arguments) in Drupal.behaviors.facetsViewsAjax.
2. Use those View settings in \Drupal\facets\Controller\FacetBlockAjaxController::ajaxFacetBlockView to execute the relevant Views.

Doing this causes Search API to cache the results and \Drupal\facets\Plugin\facets\facet_source\SearchApiDisplay::fillFacetsWithResults already looks for cached results before attempting to execute the View. It's possible this also removes the need for the condition and View execution handling in fillFacetsWithResults but I'm not sure if there are other paths that lead to that.

This method also supports the use case I have (see #14) -- an AJAX enabled View with facets and an exposed sort.

As this is a different approach than #6 I'm not including an interdiff.

Switching this to the new 2.0.x branch to see if still applies and passes.

You need to queue the 2.0.x tests manually on these old issues. I did so now.

Rewrite the patch to avoid this type of error https://www.drupal.org/project/facets/issues/3310536

Rewrite the patch for 2.0.6