Exposed filters don't work correctly in Drupal 10.1 due to GET request being used instead of POST

Patch reroll to fix pagination

Hey! thanks for creating the issue and the fixes.
I can confirm that this patch fixed the problem mentioned in this issue and also the one described in this other issue: https://www.drupal.org/project/views_ajax_history/issues/3379638 🐛 Pager index not reset when selecting exposed filter Active but the "back and forth" functionality using the browser still didn't work, I attach a patch where I add the view arguments to the url to make it work with the core changes you mentioned.

I came here with a related issue where I would need to click exposed filter twice in order for it to be removed.

I tried the patch from #6 and that fixed the double-click issue, however the browser back button does not function as intended. If I have multiple filters selected, clicking back button clears all filters instead of the last one clicked.

+1 for the patch. I didn't have any issue with the browser back as reported by arturs.v

@isaacrc
There's already an issue handling the back and forth in browser: https://www.drupal.org/project/views_ajax_history/issues/3216707 🐛 When we have selected filters and go back, all selected values was unchecked Needs review
We use this patch in conjunction with my changes in the fork and https://www.drupal.org/project/views_ajax_history/issues/3090512 🐛 Views ajax history broken after page reload Needs review to enable proper behavior when navigating.

Maybe it's best to keep this issue focused on enabling GET support.

+1 RTBC

Ran into this as well.

Tested patch #4 and it has issues with multi-select fields and pagers. I tested this scenario:

• Clean install of Drupal 10.1.x standard profile
• Create 3 article nodes, each with a tag "Test Tag"
• Create a views page that lists article nodes, exposed a filter for the Tag vocabulary, make it multi select. Enable AJAX and AJAX History. Set pager to full pager but only 1 per page
• Visit the page
• Apply a filter for "Test Tag" and submit
• Go to Page 2
• De-select the filter and submit
• You're returned to page 1, but the filter for "Test Tag" is re-selected

This is due to how the pager links handle the multi-value fields. It creates a query string like this:
?field_tags_target_id[0]=1 (it adds a index to the brackets). The JS code only looks for query strings to delete like this ?field_tags_target_id[]=1

I think we need to remove all of the query params that are indexed like that from the query string. The submitted exposed form will set them correctly as ?field_tags_target_id[]=1.

This behavior of adding indexes to the brackets is from the pager and I think has always been that way. Ideally the views pager would NOT do that - I don't think it's necessary.

Okay, I updated the merge request to remove the indexed query params for multi-value values added by pager links. I also updated it to include the change from the patch file in #4.

Please, let's stick to using the merge request for any additional changes instead of patch files. It's too confusing having both.

I was testing this with a site that uses a select2 JS widget for multi-selects and it wasn't working because the code for detecting them was based on a CSS class (which is theme-dependent and may not be there) and the "multiple" boolean attribute having a value (which is not required for boolean attributes). Fixed that as well.

Patch worked great for me, thank you!

I was seeing this problem on my sites... pulling down the latest merge request does fix the problem for me.

Back button wasn't working due views use now GET request so changed views to use GET requests instead of POST which is default for Drupal ajax api.

Rerolled #21 for the latest dev version.

Patches #21 and #22 need review

#22 fixed the issue I was having and works with the back button.

Thanks for this patch/MR. This does sort the issue out and we have tested it and are using it in a number of sites with complex views, plenty of extensions, and in combination with other modules like Views Reference/Better Exposed Filter, and find the patch to work well across the board.

The change to the selector from `.form-select[multiple=multiple]` to more generic `select[multiple]` is probably a tiny bit of scope creep, but IMHO seems reasonable here given the target class is not prefixed with `js-`, we cannot expect it to remain like that in combination with other modules.

I have updated the issue summary given its still written as if we are in Drupal 9 or earlier days. I removed the question about whether to add tests: this module does not appear to have test coverage at all, so would suggest we leave that for a follow-up wider issue if someone wants to take it on.

Committed. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.

The patch in #22 saved the day for me! It would be great to get this in a new release. ;)

Same here, patch #22 saved Drupal 10.2

Thanks to all involved in fixing this.

I agree that it would be great to have a new release to include this.

Works here, can we have a new release please?

+1