Ajax attached to Views exposed filter form does not trigger callbacks

Rerolled #83 for 10.1.x

Fixed CCF in #120

I just ran into the infamous "maximum file size" bug when attempting to Ajaxify a Views exposed filter form field with Drupal 9.5.3. I applaud the efforts to resolve this issue and look forward to a final solution.

re-roll of patch #96 for 9.5.x.

This should resolve the PHPCS errors from #124. The reroll is based on #94 against 9.5.x.

Is #126 🐛 Ajax attached to Views exposed filter form does not trigger callbacks Needs work safe to use for Drupal 9.5.5?

Thank you for any response.

I am using 9.5.8 and of the patches that could be applied none of them worked for my situation. I just have some exposed filters based on taxonomy terms (I want to update one when the other is updated) and I am still getting the "maximum file size" bug when trying I applied #96 and #108

Rerolled #116 for 9.5.x (9.5.9)

I am using Drupal 9.5.5. In all of the patches (apart from the one in #108) the changes related to the ExposedFilterAJAXTest.php
cannot be applied.

Kind regards,
Savvas

#129 works for 9.5.9 and 9.5.10, but it only works for a first request, from the second request/change select it doesn't work, it always shows me the same values of the first request, even with clean caches.

Experiencing the same problem as in #131, the first time selection for the exposed filter worked fine (after updating the page), but the second one is not working with "Maximum call stack size exceeded" error.

Patch from #129 is applied.

#126 works on Drupal 10

Patch #126 doesn't work for me with the recent Drupal 10.2.6.
We used it previously, but now we found a bug with Media Library widget.

Steps to reproduce:
1. With applied patch #126 go to the node edit page with Image field, open popup with Media Library widget.
2. In the view with existing images below the upload area go to the 2nd page (with ajax pager)
3. Select image and click Insert selected.
4. You get an Ajax error in console.

With Drupal 10.2.6 I applied the patch #116, but without tests (sorry for that).
I don't think this is the right approach because of hardcoded view id:
$this->id() !== 'media_library'
But it works good for me as a hotfix.

The patch no longer applies for Drupal 10.3. Also, this should probably be converted to use a Merge Request, so that tests can be run.

solideogloria → changed the visibility of the branch 2842525-form_views_exposed_form_alter_ajax_call to hidden.

solideogloria → changed the visibility of the branch 2842525-ajax-attached-to to hidden.

solideogloria → changed the visibility of the branch 11.x to hidden.

solideogloria → changed the visibility of the branch 10.3.x to hidden.

I created a merge request targeting 11.x. The exception for Media Library is not included. It would be better to figure out the root cause of that issue, because a user could have their own view with that ID, and it's not a good idea to hardcode an ID to exclude it.

All future changes should be applied to the MR, instead of as a patch. The GitLab pipeline won't run for patch files.

There are a couple failing tests.

1. A test added in the MR is failing: Test Failure
2. A test related to Media Library: Test Failure

I will now let somebody else have a look.

Reroll to drupal 10.3

Please ignore this patch for core maintainer
Just a reroll of #124 for old Drupal 9.5.2 with no test code

Rerolled. The same two tests are failing.

scott_euser → changed the visibility of the branch 10.3.x to hidden.

scott_euser → closed merge request !9188

The tests fail because if you actually reproduce the steps in the tests the ajax request called is missing the view_name and other parameters always added to other ajax requests when you submit the form or pager normally:

1. Import core/modules/views/tests/modules/views_test_config/test_views/views.view.test_content_ajax.yml
2. Enable views_test_exposed_filter module
3. Go to /test-content-ajax
4. Type something in the 'title' field and see the ajax request fail

So for example currently the code changes make the URL like this:
/views/ajax?status=All&type=All&title=value&langcode=All&items_per_page=50&ajax_form=1&_wrapper_format=drupal_ajax

Which is missing the details in in Drupal.views.ajaxViews[views_dom_id:CURRENT-DOM-ID-HERE] which in my case looks like this for currrent dom id:

  "views": {
    "ajax_path": "/views/ajax",
    "ajaxViews": {
      "views_dom_id:4b579992449b05c22a7bbe74079e4bbf68828038d659fd90855471f9f50b91ad": {
        "view_name": "test_content_ajax",
        "view_display_id": "page_1",
        "view_args": "",
        "view_path": "/test-content-ajax",
        "view_base_path": "",
        "view_dom_id": "4b579992449b05c22a7bbe74079e4bbf68828038d659fd90855471f9f50b91ad",
        "pager_element": 0
      }
    }
  },

Yet if you use the normal exposed filter submit form or use the pagination, you can see the view_name, view_display_id, etc from the JSON getting added to the query strings of those ajax requests.

I don't quite know how to fix that; but I wonder if the solution also needs to extend the JS in core/modules/views/js/ajax_view.js like the pager does there, to add in the additional missing details that should get passed as part of the ajax request.

Actually it does work as is, but the trigger must happen by clicking outside of the field, not as autocomplete. So perhaps autocomplete could be considered as a separate issue to keep the scope to this limited. Screencast of this working attached, Tests updated to match with comment.

1. Updated issue summary to use standard template
2. Hid patches

Tests are now passing. Ready for review.

Rebased it and seems to be causing a javascript error.

Only code change I made was https://git.drupalcode.org/project/drupal/-/merge_requests/8527/diffs?co... for typehints in tests

Tested it out and its a legitimate error caused by this. Steps to reproduce the test failure:

1. Add an 'Unlimited' media field to eg basic page
2. Upload enough images to get to multiple pages (e.g. drastically reduce the items per page at /admin/structure/views/view/media_library)
3. Click add media
4. Navigate to page 2
5. Select an image
6. Navigate back to page 1
7. Press insert selected
8. Media library window does not close

andreastkdf → changed the visibility of the branch 10.3.x to active.

andreastkdf → closed merge request !9448

Reroll of patch from #144 to be used on 10.3.5 version.

Patch #159 is working but I have the same issue mentioned in #155

The current iteration of the patch triggered the same bug as in 🐛 media_library_opener leads to massive GET requests that break varnish etc. Active for AJAX based media libraries (or any view with pagination by creating an extremely long URL path as it serializes all the POST data as GET parameters).

It ends up picking up all the POST data and using them as the exposed input query string (which is what the pager uses).

I've updated the logic so that it only picks up POST data that have been explicitly configured as being exposed by the handler.

Attached two solutions, one which picks up all exposed inputs which start with the same id → as the exposed filter (because some bespoke filters might have compound fields which have the same prefix, so they might be harder to pick up using the default exposed filter - however this is also a bit of an edge case), and one that should work for about 95% → of all use cases.

codebymikey → changed the visibility of the branch 2842525-ajax-attached-to-views-exposed-filter to hidden.

codebymikey → changed the visibility of the branch 10.3.x to hidden.

codebymikey → changed the visibility of the branch 2842525-ajax-attached-to-views-exposed-filter to active.

@codebymikey

after your last changes i got an error
Fatal errors. The uploaded file size may have exceeded the maximum file size (100 MB) that this server supports.

Patch #159 working for me correctly