Ajax attached to Views exposed filter form does not trigger callbacks

Here is a failing test for this. Haven't actually tested it with the fix yet :-)

The lack of a form-id makes the ajax framework think we have a too large file upload and throws an error that has nothing to do with this, see screenshot taken during the test after the waitforajax()

And now without the half finished line .....

Combined patch with a bit of a cleanup of #2, still fails, but with a different error now.

Current fail is because the right triggering element cannot be found. Somehow on

core/lib/Drupal/Core/Form/FormBuilder.php line 1316 the $input['_triggering_element_name'] is empty while it definitly is in the _POST.

Patch is a small improvement in javascript and an incorrect by-reference.

More cleanup.

while it definitely is in the _POST.

And this is were it goes wrong, because this is a GET form. When looking at \Drupal\Core\Form\FormBuilder::processForm you see that it just gets the GET data. So all the values that have been set in the form aren't there either, because they are done by POST. So even if the _triggering_element gets set, you still won't have any values to work with.

@dww regarding the triggering element recently in D7 (may have been entityreference changes) was fixed by this which may be related #2546700: Add support for detecting the triggering element when buttons are changed client-side

I implemented the #10 path and the ajax request returns me a very strange response: https://pastebin.com/hStUS8B0

Any suggestion?

Same issue using Drupal 8.3.2. I applied the patch but it returns me this error in the AJAX response: https://pastebin.com/gDhW6Jnd

Any suggestion?

peter-van-lierop and I have written a patch which we think fixes this issue.
We are not to sure about the underlaying code. So this needs a good review.

The patch from #17 does not work.

I got stuck on this issue for several hours until i found that this is a core issue, so what is the status of this bug or did anyone find a temporary workaround or a working patch ?

I have solved this issue in the same way as @danielbeeke and @peter-van-lierop did. But I changed only the FormBuilder class.

I attached wrong file in my previous post, sorry. '-.-

Expecting the same issue at my project.
patch at #2 fixed it.

Ajax callback is executed now, but all data and input value of the triggered element is empty.

Tested all working patches at this thread - callback execution is working, but form values of triggering element are empty.

Patch in #23 doesn't work for me :(

Have just attached patch at #23 after core update - issue is fixed.
@Pascal-, @darjanpezer could you please send output of your chrome console during ajax request?

To explain it quickly, I have a view that allows you to filter property for sale by 3 separate taxonomy terms.
The view has it's filter exposed as a block to show them on the frontpage.
The filters are also shown on the propery overview page.

Without AJAX enabled, everything works properly.

When I enable AJAX (Use AJAX option in the view, under the advanced tab)

On the property overview view page:
Nothing happens when I change one of the search terms (the goal is to filter immediately after changing a filter value right?)
When clicking the search button I get the following error in my console:

ajax_view.js?v=8.5.3:109 Uncaught TypeError: Cannot read property 'top' of undefined
    at Drupal.AjaxCommands.viewsScrollTop (ajax_view.js?v=8.5.3:109)
    at ajax.js?v=8.5.3:413
    at Array.forEach (<anonymous>)
    at Drupal.Ajax.success (ajax.js?v=8.5.3:411)
    at Object.success (ajax.js?v=8.5.3:226)
    at Object.t.success (jquery.form.min.js?v=3.51:11)
    at i (jquery.min.js?v=3.2.1:2)
    at Object.fireWith [as resolveWith] (jquery.min.js?v=3.2.1:2)
    at A (jquery.min.js?v=3.2.1:4)
    at XMLHttpRequest.<anonymous> (jquery.min.js?v=3.2.1:4)

On the frontpage:
The exposed filter block still works. (Still have to click search, but I like that)

Shouldn't the search button be hidden as well once AJAX is enabled?

Screenshot of the view settings with AJAX still disabled: https://gyazo.com/510f7aea0adcaacba756df62b3c215ef

I think changes like that in the forms subsystem would be worth getting a review from. I pinked @tim.plunkett on slack.

While working on the same kind of problem I needed a couple of adjustments, see interdiff, to make it working for me. (embedding an entity browser

Patch in #34 doesn't apply to 8.6.x
The attached patch should.

hi,
I use the patch in #36 its work and there is no error anymore but I have another problem with $form_state->getValues(); in callback function.
values empty for example in my case if dump values:

array:6 [
  "year" => ""
  "level" => ""
  "submit" => "جستجو"
  "form_build_id" => "form-zVU3h-zO_7KZRiULFZoXjGf3Cf_1PtbGyuBosPG3jqQ"
  "form_id" => "views_exposed_form"
  "" => "جستجو"
]

but if sniff packet its send year

@sadeghpro I've reached the form values through the below:
$form_state->getStorage()['view']->getRequest()->request->get('field_name');

maybe there's a better way but this works fine.

The GET vs POST issue was not in the ViewsExecutable which appears to be why the value was not there. Getting directly like in #38 does not solve all problems as, for instance, use of Better Exposed Filters still appears to leave the $form_state->isSubmitted() incorrectly as false.

Interdiff unfortunately failing, but here is the code addition found in the patch compared to #36:

diff --git a/core/modules/views/src/ViewExecutable.php b/core/modules/views/src/ViewExecutable.php
index 9ee37041c0..cfeb1eba9f 100644
--- a/core/modules/views/src/ViewExecutable.php
+++ b/core/modules/views/src/ViewExecutable.php
@@ -689,7 +689,9 @@ public function getExposedInput() {
       // Ensure that we can call the method at any point in time.
       $this->initDisplay();
 
-      $this->exposed_input = \Drupal::request()->query->all();
+      $request = \Drupal::request();
+      $this->exposed_input = $request->isMethod('get') ? $request->query->all() : $request->request->all();
+
       // unset items that are definitely not our input:
       foreach (['page', 'q'] as $key) {
         if (isset($this->exposed_input[$key])) {

Updated patch applying to latest 8.7.

Assuming here that the tests will continue to fail as no changes made there.

And a patch for 8.6.x for those who need

@scott_euser even after apply the patch getting the same error:

An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (32 MB) that this server supports.

Using patch #40 solves the file exceeding size..etc issue

However there seems to be another issue now
My custom views filter is inheriting from ManyToOne parent class, not FormBase apparently

When i set the ajax callback like this
'callback' => ['::sayHello']
the callback is never triggered

when i set it like this
'callback' => [$this,'sayHello']
i get the following js errors in the console

1 Uncaught SyntaxError: Unexpected end of JSON input
at JSON.parse ()
at drupalSettingsLoader.js:14
at drupalSettingsLoader.js:16
(anonymous) @ drupalSettingsLoader.js:14
(anonymous) @ drupalSettingsLoader.js:16
big_pipe.js?v=8.6.16:25 Uncaught TypeError: Cannot read property 'callback=Drupal%5CCore%5CRender%5CElement%5CStatusMessages%3A%3ArenderMessages&args%5B0%5D&token=_HAdUpwWmet0TOTe2PSiJuMntExoshbm1kh2wQzzzAA' of undefined
at HTMLScriptElement.bigPipeProcessPlaceholderReplacement (big_pipe.js?v=8.6.16:25)
at Function.each (jquery.min.js?v=3.2.1:2)
at r.fn.init.each (jquery.min.js?v=3.2.1:2)
at bigPipeProcessDocument (big_pipe.js?v=8.6.16:52)
at big_pipe.js?v=8.6.16:66
bigPipeProcessPlaceholderReplacement @ big_pipe.js?v=8.6.16:25
each @ jquery.min.js?v=3.2.1:2
each @ jquery.min.js?v=3.2.1:2
bigPipeProcessDocument @ big_pipe.js?v=8.6.16:52
(anonymous) @ big_pipe.js?v=8.6.16:66
drupal.js?v=8.6.16:13 Uncaught TypeError: Cannot read property 'currentQuery' of undefined
at Object.attach (active-link.js?v=8.6.16:12)
at drupal.js?v=8.6.16:25
at Array.forEach ()
at Object.Drupal.attachBehaviors (drupal.js?v=8.6.16:22)
at drupal.init.js:16
at HTMLDocument.t (ready.min.js?v=1.0.8:4)
attach @ active-link.js?v=8.6.16:12
(anonymous) @ drupal.js?v=8.6.16:25
Drupal.attachBehaviors @ drupal.js?v=8.6.16:22
(anonymous) @ drupal.init.js:16
t @ ready.min.js?v=1.0.8:4
drupal.js?v=8.6.16:13 Uncaught TypeError: Cannot read property 'ui' of undefined
at Object.attach (locale.datepicker.js?v=8.6.16:24)
at drupal.js?v=8.6.16:25
at Array.forEach ()
at Object.Drupal.attachBehaviors (drupal.js?v=8.6.16:22)
at drupal.init.js:16
at HTMLDocument.t (ready.min.js?v=1.0.8:4)

The above js errors occur on page load, not when i try to invoke the callback.

Funny thing is that when i use
'callback' => ['::sayHello']
as said, the callback is not invoked

if i change the above to
'callback' => [$this,'sayHello']

and i DONT cc/reload the page, then the callback is triggered correctly and everything goes well
if i reload the page, i get all the above js errors, and no js can be executed any more

any ideas?

Re-rolled.

hmm

I used patch #45 and it works for Block Views exposed filter, but getting error like An unrecoverable error occurred. The uploaded file likely exceeded the maximum file size (2 MB) that this server supports. while using #ajax on Page views exposed filter field element. Here what I've got is triggered element were not properly set to $form. So I just added proper page view form path for triggered element.
Also I have checked method type with $form_state instead of current request, cause if we check method type by current request, then taxonomy listing page is getting break and showing error like Notice: Undefined index: terms in Drupal\taxonomy\Form\OverviewTerms->buildForm() .
A patch against for 8.8.x. Please review.
Thanks!!

I created this issue for media library widget. Turns out to be related to this issue thread. I have patch #39 applied and also tried the other patches below that one.
When using the media library widget the user is unable to use the exposed filters. There is an ajax console log error Drupal.AjaxError {message: "↵An AJAX HTTP error occurred.↵HTTP Result Code: 20…modules/media_library/src/MediaLibraryState.php).", name: "AjaxError"} Removing the patch the user is able to use the filters again.

Did some digging around the issue is resolved when I change the following in core/modules/views/src/ViewExecutable.php line 692

      $request = \Drupal::request();
      $this->exposed_input = $request->isMethod('get') ? $request->query->all() : $request->request->all();

back to this

$this->exposed_input = \Drupal::request()->query->all();

I am developing a custom views_exposed_form_plugin and also run into this problem. Patch #39 solves it on a Drupal 8.7.5 for me.

@_dcre_ I also noticed this. For declaring the callback neither

'#ajax' => [
  'callback' => '::manualSelectFilterChangeCallback',
  'event' => 'change',

nor this works:

'#ajax' => [
  'callback' => [$this, 'manualSelectFilterChangeCallback'],
  'event' => 'change',

I need to declare the callback via the complete class path like this:

'#ajax' => [
  'callback' => 'Drupal\flexible_views\Plugin\views\exposed_form\ManualSelection::manualSelectFilterChangeCallback',
  'event' => 'change',

EDIT: Another problem is, that if my form element is in the first dimension e.g. $form['my_element'], it work's like describe above. If I wrap my element with a details element: $form['details']['my_element'], I am getting the filesize error again.

Reroll

I rerolled the patch from #49 against Drupal 8.7.x if somebody needs it.

@revati_gawas is right: checking the request method directly in the request, and not in the form_state leads to some errors: for me, the bulk operations did not work with the patch applied.

That was the part from previous patches:

--- a/core/lib/Drupal/Core/Form/FormBuilder.php
+++ b/core/lib/Drupal/Core/Form/FormBuilder.php
@@ -240,7 +240,7 @@ public function buildForm($form_id, FormStateInterface &$form_state) {
     // should be initialized to empty rather than to ['destination' => 'foo'].
     $input = $form_state->getUserInput();
     if (!isset($input)) {
-      $input = $form_state->isMethodType('get') ? $request->query->all() : $request->request->all();
+      $input = $request->isMethod('get') ? $request->query->all() : $request->request->all();

Patch mentioned in #39 worked for me. Also, the callback function mentioned in #52 works.

Still, the first dropdown values are not being passed to the second dropdown callback function.

Instead of hacking core, I achieved it using "Request" in form_alter.
I am able to fetch the values using below code:

Implemented in Drupal 8.7.6

// To fetch current state values
$request = \Drupal::request();
$default_date = $request->get('field_date_value');

// To set values in views exposed_filter form, I set in setUserInput like this
$form_state->setUserInput(['field_type' => $tid]);

Just for anyone's help.

I was having an issue with custom #ajax on a View Exposed Form with Better Exposed Filters in a Drupal 8.7.7 website.

I've used patch #56 and it fixed the situation.

Form elements with Ajax behaviors are working and the too large file exception on submission is not thrown anymore.

Hello. Patch from #56 brakes all the Bulk operations in views. Need to find a better solution than this.

Attaching fix to resolve conflict with View Bulk Operations.

Last patch was created from the wrong folder. Re-rolling.

Thanks, @dww.

Regarding item 1 at #70.
Intent of this code is to throw different type of exception before it is thrown by buildForm method.

    // In case the post request exceeds the configured allowed size
    // (post_max_size), the post request is potentially broken. Add some
    // protection against that and at the same time have a nice error message.
    if ($ajax_form_request && !$request->request->has('form_id')) {
      throw new BrokenPostRequestException($this->getFileUploadMaxSize());
    }

To my mind, this condition needs to be adjusted, because in current situation it has nothing in common with post_max_size limit.

Agreed. I've tested my scenario again (custom views filter plugin with ajax callback +vbo) - there is no any $form['secondary'] element in the form. I think it was occasionally included into the patch #49 during testing of some project-related scenario. Relying on request method type and triggering element is enough for all the situations I could test.
Patch #71 fixed both issues (with vbo and views filter ajax) for me.

The only change I may to propose is to merge isset condition:
if ($triggered && isset($form[$triggered]) && isset($form[$triggered]['#ajax']))
like this:
if ($triggered && isset($form[$triggered]['#ajax']))

You guys are life savers! I just happened to need to do this today and couldn't figure out why the callback wasn't firing! Patch 71 works for me.

Nice to see progress on this, been a while since I was last here :)

1. +++ b/core/lib/Drupal/Core/Form/FormBuilder.php
   @@ -562,6 +562,16 @@ public function processForm($form_id, &$form, FormStateInterface &$form_state) {
   +    // Allow an ajax callback while the form is operating in GET mode.
   +    // For example when using HOOK_form_views_exposed_form_alter.
   +    if ($form_state->isMethodType('get')) {
   +      $triggered = $this->requestStack->getCurrentRequest()->request->get('_triggering_element_name');
   +      if ($triggered && isset($form[$triggered]['#ajax'])) {
   +        $form_state->setTriggeringElement($form[$triggered]);
   +        throw new FormAjaxException($form, $form_state);
   +      }
   +    }
   

   This change seems to lack test coverage. And if this really needs this change outside the Views module, it would be great if we can trigger this without the Views module being involved, to show that we really need to have this in the formbuilder (because I'd prefer not to bother the formbuilder with the weird requirements of Views unless we really have to)

2. +++ b/core/modules/views/tests/src/FunctionalJavascript/ExposedFilterAJAXTest.php
   @@ -151,4 +158,27 @@ public function testExposedFiltersInModal() {
   +    $page->fillField('title', 'value');
   +    $this->assertSession()->assertWaitOnAjaxRequest();
   +
   +    $this->assertSession()->pageTextContains('Callback called.');
   

   This should really use waitForElement or something of that ilk instead of assertWaitOnAjaxRequest. We probably need to add a little wrapper to the ajax reply to make it easy to detect the change

#78.2 is because assertWaitForAjaxRequest is notoriously fickle, it has been the cause of many a random fail on Drupal CI. It has been shown that actually waiting for the change to appear is much more stable. So unless there is no change to detect, try never to use assertWaitForAjaxRequest. Since this is fairly straight forward I would not expect problems here, but best to be safe.

There are plenty of examples in #2829040: [meta] Known intermittent, random, and environment-specific test failures that in the fixes come down to 'replace assertWaitForAjaxRequest with other wait options'.

Edit: I realise I put the assertWaitForAjaxRequest in the test myself in #3 or something, but wisdom comes with the years (no idea if that is an english expression but it is a dutch one :) )

Adding #2934463: Ajax is broken in forms built within an Ajax callback as related because after submitting an ajax form exposed, the base url is lost and workaround in #2934463-11: Ajax is broken in forms built within an Ajax callback that could be useful.

#77 patch works but it breaks Media Library Widget.

After clicking "Add Media" button on the node media entity reference field, AJAX view in the popup will say "No media available.".
Trying to switch between Grid/Table display will return 403 AJAX error "ID parameter is required and must be a string."

But after clicking on "Filter" button, AJAX view works fine.

From #77:

+++ b/core/lib/Drupal/Core/Form/FormBuilder.php
@@ -562,6 +562,16 @@ public function processForm($form_id, &$form, FormStateInterface &$form_state) {
+      $triggered = $this->requestStack->getCurrentRequest()->request->get('_triggering_element_name');
+      if ($triggered && isset($form[$triggered]['#ajax'])) {

It doesn't work for me when the triggering element is grouped, e.g. $form['advanced']['element']['#ajax']

I think $form_state->getTriggeringElement() should return some value since the request is initiated by an Ajax triggering event, so the triggering element could be got by that way.

+1 RTBC for #83 on Drupal 8.9.1

Thank you all!

Doesn't this need to be tested against 9.x then backported now? Retesting...

Patch #83 on Drupal 8.9.4 looks good to me.

Patch #83 works for me if I redraw a form element at the callback function.

First problem:
I am implementing the ajax by hook_form_alter and need to validate form_state values after ajax redraw, and with this patch, the $form_state->getValues() is always empty.

I got this works gething the value by getRequest() from view executable.

$form_state->getStorage()['view']->getRequest()->request->get('field_name');

Second problem:
I works with a view that use ajax to filter. After filter the form ajax doesn't work anymore and I get this error:

page not found
Path: http://my_domain/views/ajax?_wrapper_format=drupal_ajax&ajax_form=1&category=35&nombre=&sub_category=36
Reference: http://my_domain/store
Message: /views/ajax?category=35&sub_category=36&nombre=&ajax_form=1&_wrapper_format=drupal_ajax

I got this works setting into my ajax the 'url' key. due to the view will miss this.

/** @var  $view \Drupal\views\ViewExecutable */
    $view = $form_state->getStorage()['view'];

    $form['category']['#ajax'] = [
      'callback' => 'rebuild_subcategories',
      'event' => 'change',
      'url' => Url::fromUri('base:' . $view->getPath()),
      'wrapper' => 'sub-category-ajax',
    ];

I have the same scenario, in views exposed form (with the help of better exposed filter) I am exposing some fields. And with a form alter I want to change a text field to select list with AJAX added to it.

In the mymodule.module file, I have these below code:

function mymodule_form_views_exposed_form_alter(&$form, FormStateInterface $form_state) {
  $view = $form_state->getStorage('view');
  $view_name = $view['view']->id();
  if ($view_name == 'schemes' && $view['view']->current_display = 'block_2') {
    $values = $form_state->getValues();
    if (isset($form['field_state_city_state'])) {
      $states = mymodule_state_list(); // Loads the states of my country. This field is actually a text field via this alter it has been changed to select.
      $form['field_state_city_state']['#type'] = 'select';
      $form['field_state_city_state']['#options'] = $states;
      $form['field_state_city_state']['#size'] = 1;
      $form['field_state_city_state']['#ajax'] = [
        'callback' => 'mymodule_load_city',
        'event' => 'change',
        //'url' => Url::fromUri('base:' . $view['view']->getPath()),
        'wrapper' => 'views-test-exposed-filter-test',
        'progress' => [
          'type' => 'throbber',
          'message' => NULL,
        ],
      ];
    }
    // Add placeholder for Ajax response markup
    $form['ajax_response'] = [
      '#type' => 'html_tag',
      '#tag' => 'div',
      '#value' => t('Placeholder for ajax response'),
      '#attributes' => [
        'id' => ['views-test-exposed-filter-test']
      ]
    ];

  }
}

function mymodule_load_city(array &$form, FormStateInterface $form_state) {
  $response = new AjaxResponse();
  //$response->setAttachments($form['#attached']);
  $response->addCommand(new ReplaceCommand('#views-test-exposed-filter-test', 'working!!  '));
  return $response;
}

I have applied the #83 patch and it was applied correctly but still I get the MAX file size error.

Am I missing anything here?

Regards,
Aneek

@aneek "MAX file size error."? do you have an composer error?

If you refear to your environment memory limitation maybe this can be helpful:

Call composer without memory limitations. Take careful in prod environment. It is only for dev environment.

php -d memory_limit=-1 /usr/local/bin/composer update --lock

@vacho - No composer has worked fine. No errors there. The problem that I am facing is, if you see the code that I posted, it doesn't call the callback rather moves to the file upload AJAX call. Please see the image in #3. That is the error it shows. Nothing to do with composer. Makes sense?

Regards,
Aneek

The max file size error is actually triggered from FormBuilder (by throwing a BrokenPostRequestException when form_id is empty in an AJAX request). It is explained in the issue description that it's how Views forms work (removing form_id), so it seems the patch doesn't work.

Just updating the patch to be Drupal 9.2.x compatible. Interdiff rejected because of exactly the research patch is rejected - ExposedFilterAJAXTest use statement and public static variables causing conflicts. Test view info yml updated to support core 9x. Otherwise no change.

Fixed the test case.

I have apply the patch #96, it works in most cases. But it did not work if the view has ViewBulkOperation.
After deep diving in, I found that the form_id was changed unexpectedly with the code:

$this->exposed_input = $request->isMethod('post') && $triggered ? $request->request->all() : $request->query->all();

So I add unset 03 form input values

      unset($this->exposed_input['form_build_id']);
      unset($this->exposed_input['form_token']);
      unset($this->exposed_input['form_id']);

Re-rolled patch. Please review.

The patches for this issue and #2977785: No error messages are shown for applied validation on a view exposed filter with on "AJAX" conflict so that only one can be applied cleanly at a time. This is a re-roll of #96 so that it can be applied cleanly after #2977785-32: No error messages are shown for applied validation on a view exposed filter with on "AJAX".

*Note - Do not use this patch unless you are also using the patch from #2977785-32: No error messages are shown for applied validation on a view exposed filter with on "AJAX".

Using the patch in #96 fixed my exposed view filter #ajax callback, however it then broke other #ajax that were on the page - specifically in the views content region on an add to cart button I had ajaxified.

[deleted]

Re-rolled the patch in #101 so it applies to Drupal 9.3.0-alpha1.

Patch #97 does not apply to 9.2. Possibly you have other patches affecting things?

I don't understand the point of Suresh's changes. No explanation given.

All the patches after it are based on also having another patch from a separate issue.

For now #96 is the only one that applies to 9.2 cleanly and works.

This is a re-roll of the patch from #96 so that it applies cleanly to 9.4.x-dev.

We also tried this patch and it works for our Ajax callbacks not being attached problem... unfortunately the patch has side-effects as already described in #82:

The media library widget's view opened in a modal does not work initially with this kind of solution. When the patch is applied, the exposed_data property in ViewExecutable::_build() is empty during initial load, while it shouldn't because of the configured default values for exposed filters. In our case, we added a grouped Publishing status filter to the media library view, that should display all media items initially (with options for published or unpublished only). But as the exposed_data is empty, its default Any value is not applied, but 0 is used instead, which results in only unpublished media items being visible.

Attached you can find a media library views config (based on core media's default view config) with the Publishing status filter added to the Widget and Widget (table) displays for easier testing and reproducibility.

As already described in #82, a click on the Apply filters button without changing any filters, restores the default filter values and the list is displayed correctly with all functionality again. It also restores the required media library values again (e.g. media_library_opener_id) that are needed to be able to switch to the table listing.

Does anyone has an idea how to deal with this?

...hide exported views config from files

Here is a very basic quickfix for the media library problem (because we need this urgently and this was the easiest way to achieve working media library filters again). It just adds another condition when determining exposed input that checks if the trigger was a media library widget open button. I guess this is not the correct was to deal with it, but for anybody having the same trouble, this might be a solution for now. It is based on patch from #108.

As it is only a quickfix, I also hid the file from the issue files in the summary.

Here is an updated quickfix patch that also works for nested subforms (like paragraph forms). Again based on patch from #108.

All things go by threes ;) The other quickfix patches still had problems after uploading a file in the media library and clicking "Save and select"... So here if (hopefully) the final quickfix patch for the media library (based on #108 again) with a completely different approach that does not check the triggering element's name, but checks for the media_library view ID instead.

Patch #83 works for me on 8.9.20.
Thank you very much!!

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 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 #124 no longer applies for Drupal 10.3. Also, this should probably be converted to use a Merge Request, so that tests can be run.

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, as I have little experience with tests.

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.

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

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 #3403077: media_library_opener leads to massive GET requests that break varnish etc. 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

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

There are 2 MRs both pointing to 11.x, one should be closed please.

Preferably whichever one addresses last remaining item

Fix the issue described in #155

Thanks.

Whilst testing for the #155 issue, I was unable to replicate the bug on a clean install targetting that branch.

I however did run into a separate issue where following the same instructions on a clean 11.x installation, the selected media element is not actually inserted into the page. I'm not sure if a separate media UI issue should be created for it, or addressed as part of this AJAX. But the commit for it is available here if it needs to be moved out.

@alexdoma I was unable to replicate the #168 issue. I've attached a copy of the latest PR, and if you're still having issues, please provide exact instructions on how to replicate on a clean 11.x installation with just the patch applied.

So believe the test coverage needs to be tweaked some. Running test-only change is still green https://git.drupalcode.org/issue/drupal-2842525/-/jobs/4098790

Testing this patch out in a custom form behaviour we have for a client (some exposed form alters for autocompletes), with the latest changes in the merge request, we get 400 bad request errors. I don't quite understand why. I can however see that it is due to latest versions of the merge request stripping out _triggering_element_name from the exposed input.

While I am here, going to see if I can spot anything in the tests per #172

Okay that did it (locally at least), just needed to target a different view to have the test coverage reproduce the error without the code change. Letting it run now in Gitlab CI

Okay this still needs work:

1. The tests don't reliably fail without the code change
2. I managed to still reproduce the issue even with the code change

Here's how:

Setup:

1. Change /admin/content view to use ajax
2. (Optional) Change number of items per page to 1 or 2 (to make it easy to get to pagination)
3. Enable 'views_test_exposed_filter' test module (make sure you have $settings['extension_discovery_scan_tests'] = TRUE; enable in settings.local.php so you can enable the test module)

Works now:

1. Go to /admin/content
2. Start typing in the 'Title' exposed filter and click outside
3. Callback called

Doesn't work still and triggers error:

1. Go to /admin/content
2. Click page two
3. Start typing in the 'Title' exposed filter and click outside
4. "Oops, something went wrong." Error shown with 404 in the console log (400 prior to #173)

I can see why; the GET request in the working scenario is to "/admin/content?ajax_form=1&_wrapper_format=drupal_ajax", but once you e.g. use pagination it seems views ajax is changing that GET to instead target "/views/ajax?page=1&ajax_form=1&_wrapper_format=drupal_ajax".

If anyone has any tips to help understand why/help stop that from occurring, much appreciated.

As far as I can tell, if we find a way for the URL that gets set in ajax.js to consistently be the route of the View itself (as it is on initial load) things should all start falling into place.

Thanks scott_euser for the last addition fixing the issues in custom forms behaviour and for explaining what still needs work on this issue.

Sorry for the MR above (that I now closed), please ignore (I wanted to make an MR targeting 10.4.x, but this is not needed, the diff from the active MR is applying on 10.4.x too)

Just confirming that I tested changes from @VladimirAus and continue to have the error described in #175

There are still two MRs targeting main. One should be closed, right?

Either resolve the merge conflicts in 8527, or close it. MR 10296 is mergeable, but doesn't contain changes to the media_library JS.