Query string is appended multiple time after each AJAX request

I think the problem is in ajax.js:

ajax.options.url += Drupal.ajax.WRAPPER_FORMAT + '=drupal_' + (element_settings.dialogType || 'ajax');

That runs without checking if ajax.options.url already has that query param in it.

The submitted patch checks if the URL already contains FORMAT_WRAPPER and does not append it a second time.

@bruvers fix looks to have fixed the repeated URL argument.

Attached is a screenshot of traffic captured following the instructions provided in the issue.

Notes:
- originally I wondered why the code didn't replace existing URL values with subsequent values, but @bruvers fix is more elegant, and uses a "first value passed", instead of "last value passed" approach.
- note that there are > 100 coding standards issues with the views module (out of scope for this issue) according to the coder project.

Would be good to get nod_ to take a gander at this, since it affects JS.

My brain is wrecked right now but it seems possible that the format would change after a request. It means we do not only have to detect the presence of the variable but also it's value.

Updated the patch. It now replaces the value of FORMAT_WRAPPER if it has been set earlier instead of just leaving it unchanged.

Same patch as #9, just changed variable name for consistency with comments.

confirmed testing process. Functionality still behaves as expected.

I am also not aware of any case where the wrapper format changes, but the code should still work.

+++ b/core/misc/ajax.js
@@ -427,15 +427,19 @@
+      var regexPattern = new RegExp(Drupal.ajax.WRAPPER_FORMAT + '=\\w*');

Are we sure that this regex is good enough? Don't we really mean select up the next & or the end? Yes atm wrapper formats don't contain odd characters but it's not hard to imaging a - getting into one.

The new patch improves the regular expression: ignores case and the parameter value now matches any character except the ampersand "&". This should cover any special characters that could appear in the URL.

Tested patch from #13 , it solved the issue.

There are screenshots with request strings.

1. +++ b/core/misc/ajax.js
   @@ -427,15 +427,19 @@
   +    if (ajax.options.url.indexOf(Drupal.ajax.WRAPPER_FORMAT) === -1) {
   

   this condition is also case sensitive.

2. +++ b/core/misc/ajax.js
   @@ -427,15 +427,19 @@
   +      var regexPattern = new RegExp(Drupal.ajax.WRAPPER_FORMAT + '=[^&]*', 'i');
   

   shouldn't it missing g flag? To clean them all in edge cases.

3. +++ b/core/misc/ajax.js
   @@ -427,15 +427,19 @@
   +      var regexPattern = new RegExp(Drupal.ajax.WRAPPER_FORMAT + '=[^&]*', 'i');
   

   although it works, I think it still worth to add hardcoded `drupal_` namespace to regex.

4. var WRAPPER_FORMAT = '_wrapper_format';
   var regexPattern = new RegExp( WRAPPER_FORMAT + '=[^&]*', 'i');
   "test?should_not_replaced_this_wrapper_format=z".replace(regexPattern, '!!!OUCH!!!');
   

   additional to above point, it's rarely but may occur.

Rerolling the patch #13

Also attaching screenshot.

This patch fine for me..
+1

Patch on #22 still applies fine.

This is blocked on tests.

Copying my comment from #2905676: ajax.js overwrites WRAPPER_FORMAT when already specified, which is apparently a duplicate:

I believe this issue is confusing because of #2504709: Prevent _wrapper_format and ajax_form parameters from bleeding through to generated URLs.

There are a couple things to consider here:
1) _wrapper_format is present on links when it shouldn't be, because of the above issue
2) Appending multiple values for the same key is confusing, and the behavior is not documented. Currently the last value "wins"
3) If you purposefully specify a _wrapper_format, it is currently ignored (solved by my patch)
4) Manually specifying a _wrapper_format may be incorrect, as explained by @droplet in #9

The fix proposed in #10 to me seems like the opposite of the previous fix, and also seems like a workaround for the other issue.

Next steps:
Fix the linked issue so that _wrapper_format doesn't bleed through to links.
Investigate using another mechanism for specifying the wrapper format on a link (not query string)

Not exactly sure if this is the right issue to address this but here I go..

Currently I am having issues with the wrapper_format bleeding through my urls in the Core modal popup, this is my scenario:

I am using Drupal core modal popup and rendering node detail in the popup.

    return [
      '#type' => 'link',
      '#title' => $this->t('Read on'),
      '#url' => Url::fromRoute('entity.node.canonical', ['node' => $entity->id()]),
      '#attributes' => [
        'class' => ['use-ajax'],
        'data-dialog-type' => 'modal',
        'data-dialog-options' => Json::encode([
          'title' => '',
          'maxWidth' => 915,
          'width' => '80%',
          'height' => 'auto',
          'maxHeight' => '3000',
          'closeOnEscape' => TRUE,
          'closeText' => $this->t('Back to selection'),
        ]),
      ],
    ];

In this popup multiple fields and entities are rendered from the node detail view. Some of these fields are rendered links, the wrapper_format is bleeding trough in all these links and when clicked I see this:

As a workaround we are going to remove the wrapper_format query parameter from all urls in the popup with javascript. Does anybody have a better solution for this? Also tried removing these query parameter with hook_link_alter(), but this doesn't work.

Still experiencing query strings being appended multiple times. Unsure if fixing this might contribute to a solution for #2934463: Ajax is broken in forms built within an Ajax callback, however here's my best-effort plain reroll of the 3 year old and no longer applying patch #22. I'm not a JS expert, so the tests might give an indication if I got it right or not.

@Falco010: No, that's the other issue, see #2504709: Prevent _wrapper_format and ajax_form parameters from bleeding through to generated URLs.

Tests seem to be passing. The fix doesn't seem to help much with any other issues (as tim.plunkett said, the last value "wins" anyway), but it doesn't hurt either and it is definitely cleaner now, see the before/after screenshots with my working and my failing AJAX callback (lines 2 and 3):

Before:

After:

Rerolling for drupal 9.2.7

Re-roll for Drupal 9.5.0

Fixed CCF for #48.
Please review.

Failures in last builds

Also was previously tagged for tests in #26 which still needs to happen.

I'm facing an issue with Drupal 10.1 where the Media Library pagination doesn't work, which might be related to this.

I get 414 URI-Request too long error.

Here's a screencast:
414 error with media pagination

That's more likely to be solved by #3348789: Compress ajax_page_state.

Getting the same issue as #54 now, we cannot paginate any Media Library widgets in use and the patches in #3348789: Compress ajax_page_state won't apply (10.1.3).

I set it as needs review for the MR https://git.drupalcode.org/project/drupal/-/merge_requests/4685 I created.
It contains the fixes from #49 but does apply to Drupal 9.5.x.
For newer versions we would require a rebase or a newer branch.

11.x is the current development branch.

Has anyone tried to see if https://www.drupal.org/project/drupal/issues/3348789 fixes the issue?

Also was previously tagged for tests which are still needed

thanks.

I can confirm the commit on the issue #3348789: Compress ajax_page_state helps by reducing the size of the request uri, but doesn't solve the duplication when consecutive ajax calls get triggered on a Drupal 10.1 instance.

#3403077: media_library_opener leads to massive GET requests that break varnish etc. looks like the worst culprit here. If people are seeing the same thing with other AJAX implementations it would be good to document that here.

Bumping to major because this can cause URLs that are too long for varnish and etc.

We have found this issue when trying to update a view to use facets v3 as exposed filters and ajax enabled. The view have 7 exposed filters (6 of them are facets) and 1 exposed sorting criteria. The error happens after changing the filters a few times (not too many), for example, applying the filters one by one.

UPDATE: We are facing the issue locally with apache, without varnish. The url raises more than 10k characters long. For example the "sort_by" parameter is duplicated 7 times

Finally, our issue was coming from the following patch: https://www.drupal.org/project/drupal/issues/2605218#comment-15002530

After applying the latest version of the MR on #2605218: Views Block Display skips preBlockBuild() call on ajax rebuild the issue went away!

I think using URLSearchParams() instead of RegExp(), it makes code more simple than patch #49.
I committed for the 2508796-query-string-for-11.x branch.

I have the same issue as #56 on 10.2.5. The query parameters are duplicated and is too long for our WAF policy.

I am not using facets module.

Patches I have tried:

• Ajax Pager broken after upgrade 10.0.9 to 10.1.2
• #3348789: Compress ajax_page_state
• Ajax attached to Views exposed filter form does not trigger callbacks
• Page index isn't reset when use AJAX for Views module
• The patch from #49 does not work on 10.2.5