Views - update filters block on ajax request

Wondering is it possible to reproduce this with just Drupal Core?

Might be possible to run into this in Drupal core by using the "Exposed form in block" option if anything in that block should be conditional— at any rate fixing this is necessary for Search API + Facets 3.x to work properly with exposed form in block, where the whole idea of facets is that as you filter inapplicable ones are removed, counts are updated, etc.

I would bump this to major, personally. It is not only Views AJAX History that is affected.

Oh more important the patch fixes it! So RTBC from the "it works" perspective, needs review from the core code quality perspective.

I'll add the contrib blocker tag as well for that usecase.

Will need test coverage to show this issue.

The problem here is that is hard to reproduce without either facets 3.x or views ajax history. I'm not sure how to add tests for this.

The patch on #3 is working fine in case there's a single exposed form block. In case there are many instances it will replace only one of them. I'm adding here a modified version using data-drupal-selector instead of the id as selector for the replacement.

I have facets 3.x and this patch working well to provide a views exposed facet filter (mixed with other exposed filters). It works on our local dev environment as well as Dev server environment. But for some reason i get this ajax error from our staging environment:

Trying to access array offset on value of type null in /var/www/html/core/modules/views/src/Controller/ViewAjaxController.php on line 214

the error is from code added by this patch. Checking the html source and there is a [data-drupal-selector={$form['#id']}] attr. Any thoughts on what is causing this?

A little unclear but it seems like this patch may only be for cases where exposed filters are in a block; but Facets 3.x to combine with other views filters; this is not supported. The filters must be part of the view - not exposed in a block. I"ll test without this patch; although we also have instances on other pages where we do use filters in an exposed block (with ajax).

Also, not sure what your numbering is for the patch in #16 - it is supposed to use the issue nid: 3090504. What is 13327307?

Yes, removing this patch and my facets exposed filters (not in a block) combined with other views exposed filters now works correctly on all environments. Of course the places where i use exposed views filters in blocks, no longer work with ajax. PErhaps this patch needs to only apply where needed? I'll take a look at that tomorrow.

Although i think our solution is no longer needing this patch, i did try to debug what it was doing. I think the method $display_handler->usesExposedFormInBlock() isnt doing what is intended here. I think it is only testing if this is an option; not the value of the option. So even though i don't have my exposed form in a block, this is returning true regardless and the code fails because the next line: $form = $display_handler->viewExposedFormBlocks(); returns null (since i do not have this enabled). This causes my error.

Also, is the work here not the same as being looked at here: ✨ Exposed forms in a block are not currently updated when Ajax filtering is executed Needs work ?

We run in the same or a similar issue as @liquidcms. There are situations in which the display handler behaves like there is an exposed form block while there isn't (a real) one. I think the patch should cater for these situations.

ricovandevin → changed the visibility of the branch 3090504-views---update to hidden.

Patch fixes issue for 10.3.

Thanks but MRs should be pointed at 11.x

Was also previously tagged for tests which are needed still

Read this thread and ✨ Exposed forms in a block are not currently updated when Ajax filtering is executed Needs work . Also evaluated current and previous approached in patches and MRs.

Because the other issue has found a close-enough solution to cover this issue with tests and there were more activity on that issue, please allow me to close this one as duplicate and continue the work in the other other.

Credits should be transferred to the other issue.