Exposed filters get values from url when ajax is on

Hey, here is an update of myha's patch for 8.9.x. It works for me, thanks!

The patch in #5 works well for me.

LGTM

This needs some test coverage.

I had the same issue and patch #5 solved it for me.

Functionality LGTM.

Yes, #5 seems to do it. However, after submitting an exposed filter change, I see the views results and exposed filter being out-of-sync with the URL displayed in browser. Shouldn't JS update also the URL in the browser's address bar? For instance, I'm doing a filtering using the exposed form, then I want to share this search with a colleague but I'm sending them a wrong URL. Maybe this needs some usability input? I'm tagging with "Needs usability review" to get some guidance on the expected behavior.

Tried to write a test but I cannot replicate the error. @myha, could provide steps to replicate the bug as a test?

However, I still need #12. I'll move that part to #343535: Enable bookmarking of AJAX views

Updated the patch to work with Drupal 9.3.x and 9.4.x
Only for the process of upgrading from Drupal 8 to Drupal 9

Fixed Drupal CS issue of patch #15.

I have a similar issue but with pages. If the page query parameter is set, then it is used in ViewAjaxController even though it is not in the POST data.
This creates weird behaviors, for example sending users to a page that does not exist for the current set of selected exposed filters.

Thanks for the patch. Works great.

None of these patches work against drupal ^10.1 or ^11

Here's a re-roll

And fix the path

Was previously tagged for tests which still appear to be needed.

And issue summary could use some attention.

Thanks

This patch seems to break #343535: Enable bookmarking of AJAX views when both are applied.

Re-rolled against 11.x and 10.2.x

Still working for me, still needs tests

hiding MR 1484 to minimize noise, but please unhide if someone wants to untangle it.

Patch on #28 didn't work for me using facets v3.

I'm uploading a new patch using a simpler solution, skip url querystring on the settings object being passed to the ajax method on javascript. By this way, all the input from the form is being sent, but the querystring is not, so no override on parameters is raising the server.

patch #29 worked for me, Drupal 10.2.6 thanks!

I have improved the approach taken by #29 in order to only remove the inputs existing in the exposed form from the URL used by AJAX.

I did this because I found a problem using the media library with this patch applied. The steps to reproduce the problem are the following :

- Open the media library modal of a field widget
- Use the exposed form in the media library modal and send the form to filter the results
- Select any media and click insert
- You will get the following error: "The opener ID parameter is required and must be a string."

This happens because the patch in #29 is removing the query parameters required by the media library (in addition to the ones present in the exposed form) when the AJAX call is done.

I messed up with the paths.

This version has the same code but with the correct paths.

Patch #32 is using "this" instead of "that" in a context where this is the windows object. Here's a patch fixing it

Patch #33 has some issues for me. It operates with form values, so if I have some value in URL, uncheck it, apply filters and then check other value, both values appears checked, because form data doesn't contain value key if all options are unchecked. Also in my case I have multiple values for my filter, so in URL it appears as manufacturer[0], manufacturer[1] etc. And in form adata it appearc as manufacturer[] (with empty brakes). To handle this I splitted filter names by openig square brake and now it works for me.

The only patch version that works for me in 10.2.6 was the one in #34. However, it fixes only the tag filtering, those are respected now but the problem is results are no longer returned.

I ran into the same issue as #31 with the opener_id error when trying to use media library items after using the views exposed filters to search for something. The patch in #34 seems to be working fine for me and I haven't noticed any issues with filtering so far.

Core Version 10.2.6

Tried to fix Javascript lint. Search and replaced $exposed_form with camelcase $exposedForm. Reduced lint errors from 20 to 18.

Tested it in drupal 11 with below description.

1. created a view
2. created the filter of authored on field and exposed it
3. tested the filter field with before adding ajax to exposed form.
4. tested the filter field with after adding ajax to exposed form.

Before adding ajax, filter parameters are taken from url and giving expected output.
After adding ajax, filter parameters which still exist in url are not taken to get results.

It is working as expected.

Below is the screen shot of before adding ajax.

Below is the screen shot of after adding ajax.

This will get more visible if #343535: Enable bookmarking of AJAX views is merged, because then a lot more AJAX requests will be made with existing GET parameters in the URL.
I will try to find a way to show this in a test.

I added a test that shows the problem.

I tried reverting the camel case changes locally but it makes yarn run lint:core-js-passing complain:

/media/pierre/Projets/workspace/drupal-core/core/modules/views/js/ajax_view.js
  176:20  error  Identifier '$exposed_form' is not in camel case  camelcase
  182:5   error  Insert `··`                                      prettier/prettier
  182:5   error  Identifier '$exposed_form' is not in camel case  camelcase

Hiding patches and closing old MRs

Following the steps I get a request like

https://drupal-11x.ddev.site/views/ajax?status=All&title=&type=All&_wrapper_format=drupal_ajax&title=&type=All&status=All&view_name=content&view_display_id=page_1&view_args=&view_path=%2Fadmin%2Fcontent&view_base_path=admin%2Fcontent&view_dom_id=163f73bb84d4e170f0b939de25d6c337ec0daf0d5e472897f73c099a6e1eb94f&pager_element=0&_drupal_ajax=1&ajax_page_state%5Btheme%5D=claro&ajax_page_state%5Btheme_token%5D=U8_NBi2POrE9U1ELs8h7ziadng1Svy8k__iIvXtLat0&ajax_page_state%5Blibraries%5D=eJx9j20OwjAIhi_UbWfwJIZ2ZKuy0gCdH6e36hqjS_zTwMMDeevjdMwx4-C3wgUC4WGUkoH6BGtn4HWjE7EH6tRuFNPkAifDqxWg5n9IV42z_leMmTxIlQTbGILFFV_bX7ymIJwRRpQ9F9TMSevifqZIGOzNE8sCFO_odGaxUKyprXdbpqFl--l71AAZD-MSkyuK0g486z7Wz6lbI150eL09nOD6BRYeC-EDDheR7w

After applying the MR

I get

https://drupal-11x.ddev.site/views/ajax?_wrapper_format=drupal_ajax&title=&type=All&status=All&view_name=content&view_display_id=page_1&view_args=&view_path=%2Fadmin%2Fcontent&view_base_path=admin%2Fcontent&view_dom_id=6bd75558a30df1be7b7f74ebc9fc473a68a2dc3c5e496a831679f7aed2d7155a&pager_element=0&_drupal_ajax=1&ajax_page_state%5Btheme%5D=claro&ajax_page_state%5Btheme_token%5D=U8_NBi2POrE9U1ELs8h7ziadng1Svy8k__iIvXtLat0&ajax_page_state%5Blibraries%5D=eJx9j20OwjAIhi_UbWfwJIZ2ZKuy0gCdH6e36hqjS_zTwMMDeevjdMwx4-C3wgUC4WGUkoH6BGtn4HWjE7EH6tRuFNPkAifDqxWg5n9IV42z_leMmTxIlQTbGILFFV_bX7ymIJwRRpQ9F9TMSevifqZIGOzNE8sCFO_odGaxUKyprXdbpqFl--l71AAZD-MSkyuK0g486z7Wz6lbI150eL09nOD6BRYeC-EDDheR7w

Not the best with nightwatch review and test-only pipeline doesn't work with nightwatch But

browser.assert.strictEqual(
              url.searchParams.getAll('title').length,
              1,
              'Duplicate title parameter',
            );

Should show the duplicates so believe it's valid coverage

Going to mark.

had a comment on the MR waiting for several weeks, sorry about that

This issue also manifests in the Media Library modal when using exposed filters with multi-value select fields (e.g. a folder/directory filter).
Steps to reproduce with Media Library:

1. Open a Media Library modal via a field widget (e.g. an image field on a node edit form)
2. Use an exposed filter with a select[multiple] element to filter results
3. Change the selection and apply filters again
4. Inspect the AJAX request — filter values from previous selections are duplicated in the payload

What happens in the payload:
The directory[] filter values were being sent three times - once from the accumulated URL query string embedded in view_query, once from the serialized form data, and then the new selection appended at the end. The result was that old selections were never cleared.

Before and After patch videos attaches for reference.

Confirmed working on Drupal 10.5.6 with the Media Library widget.

Now that #343535: Enable bookmarking of AJAX views has been committed, this bug basically breaks AJAX exposed filters after the first submit so we should really get this fixed.

Fact some tests had to be updated to pass makes me worried this will be a BC for contrib tests.

The order of the parameters in PaginationAJAXTest was changed by #343535: Enable bookmarking of AJAX views: https://git.drupalcode.org/project/drupal/-/commit/9c8eb293cae3114a76b95...
This MR reverts to the previous order. (It is a side effect, but you could say it fixes the BC break from #343535: Enable bookmarking of AJAX views.)

Good to know! Left a comment on the test though.

Maybe a test in ExposedFilterAJAXTest can be expanded?

Rolling patch (without tests) for Drupal 11.3 if someone is updating their site and getting composer errors

from https://git.drupalcode.org/project/drupal/-/merge_requests/10230/diffs (#34)

This looks like it could be a duplicate of #3273334: Unable to unselect a multi select exposed filter in ajax view