Compress ajax_page_state

However, we need to figure out whether bc is necessary - some contrib modules might inspect the array. One possible way would be to decompress the query string and replace it in the incoming request, essential upcast it, but... not sure what that looks like yet.

I think that should indeed be feasible!

+++ b/composer.json
@@ -59,7 +59,8 @@
+            "php-http/discovery": true

is that required?

There doesn't seem to be a lot of contrib use. Not sure about custom modules.

See http://grep.xnddx.ru/search?text=ajax_page_state&filename=

1. Agreed!
2. I could be convinced either way 🤓 I think I have a slight preference for consistency?

+++ b/core/misc/ajax.js
@@ -827,10 +827,7 @@
-    const pageState = drupalSettings.ajaxPageState;
-    options.data['ajax_page_state[theme]'] = pageState.theme;
-    options.data['ajax_page_state[theme_token]'] = pageState.theme_token;
-    options.data['ajax_page_state[libraries]'] = pageState.libraries;
+    options.data.ajax_page_state = drupalSettings.ajaxPageState;

We probably now want an @see \Drupal\Core\Ajax\AjaxPageStateSubscriber?

CCF fix #23.

Should this be removed from the 10.1 target list?

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Thanks for this work on this so far everyone. If anyone else needs it for D9 I have created the patch based on 3348789-37.patch. We have been looking at the various patches for D9 to allow Ajax to make get requests so need this to wrangle the query parameters into a nicer looking (and shorter) string.

EDIT - Hmm, currently can't get my own patch to apply. I think it must be due to the other patches that are also being applied to the same bit of file that I am using.

Re #41
Yes because I am already adding the patch https://www.drupal.org/files/issues/2023-03-30/956186-174-reroll-95-185.... from #956186: Allow AJAX to use GET requests the patch doesn't work so attached is an additional version that is dependent on that patch from #956186: Allow AJAX to use GET requests.

I must have missed something that is required for D9.5.x that isn't needed in the D10 & D11 patches as trying to use it causes js errors in AjaxResponse due to all of the libraries being included, which throws the "LoadJS" in core/assets/vendor/loadjs/loadjs.min.js, this stops the other js files from loading that did actually need loading.

Worked out that my backport patch was simply missing the new core/lib/Drupal/Core/StackMiddleWare/AjaxPageState.php file and service config, sorry.

I have also added a tweak to the core/lib/Drupal/Core/EventSubscriber/AjaxResponseSubscriber.php that is already part of D10 core to use $event->getRequest()->get(static::AJAX_REQUEST_PARAMETER).

Attached are the new versions of the D9.5.x patches.

Thanks for the work Altcom! Super good.

When attaching patches, it's very useful to keep the same patch name and increment the patch number to match the comment number. This makes it easier when applying and testing patches to keep them straight, I can do 37,38,44 etc.

Ajax Views pagers are not working in 10.1. That issue links here, are we intending to fix views Ajax paging with the work here or should I look into it separately in 3384852?

https://www.drupal.org/project/drupal/issues/3384852

Re #40

Drupal\Tests\media_library\FunctionalJavascript\WidgetViewsTest
No idea yet, seems to work in manual testing unless I'm missing a step.

If I first click "Apply filters", then select media and click "Insert selected" I see the POST /media-library request URL includes uncompressed ajax_page_state and response code is 500:

Symfony\Component\HttpFoundation\Exception\BadRequestException: Input value "ajax_page_state" contains a non-scalar value. in Symfony\Component\HttpFoundation\InputBag->get() (line 37 of vendor/symfony/http-foundation/InputBag.php)

#0 core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(34): Symfony\Component\HttpFoundation\InputBag->get()
#1 core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#2 core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#3 index.php(19): Drupal\Core\DrupalKernel->handle()
#4 {main}

However this patch is not compatibile with D10.1.3.
Is there any progress for D10 release also ?

Seemed to cause a number of failures. May all be related

ValueError: func_get_arg(): Argument #1 ($position) must be less than the number of the arguments passed to the currently executed function

We are having the same issue as reported in https://www.drupal.org/project/drupal/issues/3348789#comment-15242707
We applied the updated patch in https://www.drupal.org/project/drupal/issues/3348789#comment-15242845
But now, the Media Modal will not open.
It appears that the array is getting passed and causing a scalar issue.
Seems to stem from ... https://www.drupal.org/project/drupal/issues/3162016
We are seeing both the compressed ajax_page_state and the uncompressed array in the URL when inserting media.
Thank you for your work on this issue.

@catch Just going back to #36
I included that change in the 9.5.x patch but I'm not sure that change removing the isset($ajax_page_state['theme_token']) should be there.

The reason that the 'theme_token' var is missing in the ajax requests is because the System module deliberately excludes it when building the 'ajaxPageState' settings in system_js_settings_alter():

      // The theme token is only validated when the theme requested is not the
      // default, so don't generate it unless necessary.
      // @see \Drupal\Core\Theme\AjaxBasePageNegotiator::determineActiveTheme()
      $active_theme_key = \Drupal::theme()->getActiveTheme()->getName();
      if ($active_theme_key !== \Drupal::service('theme_handler')->getDefault()) {
        $settings['ajaxPageState']['theme_token'] = \Drupal::csrfToken()
          ->get($active_theme_key);
      }

So for the default theme the theme token is not added, and so

  public function applies(RouteMatchInterface $route_match) {
    $ajax_page_state = $this->requestStack->getCurrentRequest()->get('ajax_page_state');
    return !empty($ajax_page_state['theme']) && isset($ajax_page_state['theme_token']);
  }

returns false for the default theme which I guess is to 1. remove some unnecessary data from the ajax object; and 2. skip calling the determineActiveTheme method which is just going to return the default theme. This means that ThemeNegotiator::determineActiveTheme fallsback all the way to the DefaultNegotiator::determineActiveTheme which just returns the default theme.
When we remove the theme_token check from the conditional in AjaxBasePageNegotiator::applies it leads to a php notice as the AjaxBasePageNegotiator::determineActiveTheme expects it to be set when it does $token = $ajax_page_state['theme_token'];.

Attached are new Drupal 9.5.x versions without the change to the condition in AjaxBasePageNegotiator::applies

@catch
I have pulled in the latest changes you have committed to your 11.x issue branch except the changes in https://git.drupalcode.org/project/drupal/-/merge_requests/4853/diffs?co... as the comment says '@todo Uncomment new method parameters before drupal:11.0.0.' so I have left them as they were.

Re your restoring of the isset - not sure if you intended to write it that way or not but the change at https://git.drupalcode.org/issue/drupal-3348789/-/commit/a1c7a99b0d2eb2c... is wrapping the isset() within the !empty():
return !empty($ajax_page_state['theme'] && isset($ajax_page_state['theme_token']))
Original code was:
return !empty($ajax_page_state['theme']) && isset($ajax_page_state['theme_token']);

Removing the code change from AjaxBasePageNegotiator has the happy by product of removing the dependency on Allow AJAX to use GET requests [#956186] as the patch no longer trying to change the line under the one this issue patches in D9.5.x

Also - confirming that the latest changes fix the issue reported in #50 with the uncompressed ajax_page_state values being passed in the Media Library view. On D9.5.x I was getting an error trying to use the bulk operation form but that is now fixed.

Thanks @catch,

Applied the MR as a patch for D10.
Only patch that would not apply for D10 was the test in a/core/modules/field_ui/tests/src/Functional/FieldTypeCategoriesIntegrationTest.php because this file does not exist in D10.
all the other patches applied fine.

However, we are still having an issue in the Media Library.
Specifically, in the url, we are seeing compressed ajax_page_state variable, but we are also seeing the uncompressed version for theme and libraries when we insert the image found after filtering.
Note : this only happens after filtering the media library then inserting.

We are now looking at the Media Library to see if it's adding the uncompressed version.

@pelicani

If you are using Cloudflare and since the ajax_page_state is very long, the response of the media pager will be 500 when you click the pager number second.

Thanks all.

@catch

Attaching the patch we created from the MR.
https://www.drupal.org/files/issues/2023-09-27/KAL-1754-compress-ajax-pa...

I'll walk through it today to double check I grabbed the latest changes.

Our issue is the same as reported in https://www.drupal.org/project/drupal/issues/3348789#comment-15242707
My initial comment is here ... https://www.drupal.org/project/drupal/issues/3348789#comment-15244675

Better steps to reproduce involve adding a console.log to the ajax.js file.

// If no Ajax callback URL was given, use the link href or form action.
if (!this.url) {
const $element = $(this.element);
if ($element.is('a')) {
this.url = $element.attr('href');
} else if (this.element && element.form) {
this.url = this.$form.attr('action');
}
console.log('url built: '+this.url);
} else {
console.log('url exists: '+this.url);
}

https://www.drupal.org/files/issues/2023-09-27/Screenshot%202023-09-27%2...

This occurs when we add an image using the media library and filter the images then select one to insert.
On insert, we get the issue.
I hope this is clear, but I can post additional screenshots if necessary.

@aloneblood
Our issue is on a privately hosted environment with no Cloudflare

Thank you for all the work you do.

@catch

Thank you for looking at this.

I see the else if is in there, line 354, it's a patch to the patch.

@catch

I hear you, that you don't think the issue is in Media Library, but, well, we are still going to poke around in there.
No offense.

In the MediaLibraryUiBuilder.php on line 335 the view request is set...

// Make sure the state parameters are set in the request so the view can
// pass the parameters along in the pager, filters etc.
$view_request = $view_executable->getRequest();

This creates a request parameter for ajax_page_state that does contain the uncompressed libraries that are breaking the URL.

I'm having a hard time removing it.
We set the library to null, but that broke other things.
Good times.

@catch

Thank you for being so active on this issue with us!
We applied the latest but still got the uncompressed ajax page state in the URL.

Then, @markie found another file to adjust, MediaLibraryState.php and added a change to line 116

if ($query->has('ajax_page_state')) {
$query->remove('ajax_page_state');
}

// Once we have validated the required parameters, we restore the parameters
// from the request since there might be additional values.
$state->replace($query->all());
return $state;

This removed the ajax page state in the url for good.
OMG, yay, w00t, huzzah, giggity!

I've been looking at this for a week and am so ready to NOT be looking at it any more.

Note : @markie is going to update the MR

Updated the MR with a change in the MediaLibraryState.php file. This resolved our issue. I think it might remove the need to change the MediaLibraryUiBuilder.php, but why not have both. We found that when opening the media library, and then doing a filter, the un-compressed ajax_page_state was still getting passed when inserting the selected item, causing a 400 error yet again. This change to the state resolved it. Hope this helps.

> vendor/bin/phpcs --standard=core/phpcs.xml.dist --parallel=$(nproc) -- 'core'

FILE: /workspace/drupal-3348789/core/modules/media_library/src/MediaLibraryUiBuilder.php
----------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------------------------
 5 | WARNING | [x] Unused use statement
----------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------------------------

Time: 1 mins, 0.44 secs; Memory: 10MB

Resolved

Added test coverage to the MediaLibraryState changes and once I remembered how dataProviders worked, everything passes.

@catch Re the change in #66 to the Drupal\Core\Theme\AjaxBasePageNegotiator::applies, if the && isset($ajax_page_state['theme_token']) is removed then we have to do something about line 78 in Drupal\Core\Theme\AjaxBasePageNegotiator::determineActiveTheme because every call to this will cause a PHP warning.

"Warning: Undefined array key "theme_token" in Drupal\Core\Theme\AjaxBasePageNegotiator->determineActiveTheme() (line 78 of .../core/lib/Drupal/Core/Theme/AjaxBasePageNegotiator.php)

It could just be a simple as changing it to

   public function determineActiveTheme(RouteMatchInterface $route_match) {
     $ajax_page_state = $this->requestStack->getCurrentRequest()->get('ajax_page_state');
     $theme = $ajax_page_state['theme'];
-    $token = $ajax_page_state['theme_token'];
+    $token = $ajax_page_state['theme_token'] ?? '';
 
     // Prevent a request forgery from giving a person access to a theme they
     // shouldn't be otherwise allowed to see. However, since everyone is

as $this->csrfGenerator->validate() expects the $token var to be a string? So if the theme is not the default AND the theme_token is not set the var is an empty string.

We were also getting errors

TypeError: Drupal\Component\Utility\UrlHelper::uncompressQueryParameter(): Argument #1 ($compressed) must be of type string, array given, called in .../core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php on line 35

due to the ajax_page_state already being uncompressed. This was coming from an old custom ajax callback that did ajax get requests before issue #956186 that we have now changed but just for defensiveness how about a condition before the code tries to uncompress the var:

   public function handle(Request $request, $type = self::MASTER_REQUEST, $catch = TRUE): Response {
     if ($request->request->has('ajax_page_state')) {
       $ajax_page_state = $request->request->get('ajax_page_state');
-      $ajax_page_state = json_decode(UrlHelper::uncompressQueryParameter($ajax_page_state), TRUE);
+      if (is_string($ajax_page_state)) {
+        $ajax_page_state = json_decode(UrlHelper::uncompressQueryParameter($ajax_page_state), TRUE);
+      }
       $request->request->set('ajax_page_state', $ajax_page_state);
     }
     elseif ($request->query->has('ajax_page_state')) {
       $ajax_page_state = $request->query->get('ajax_page_state');
-      $ajax_page_state = json_decode(UrlHelper::uncompressQueryParameter($ajax_page_state), TRUE);
+      if (is_string($ajax_page_state)) {
+        $ajax_page_state = json_decode(UrlHelper::uncompressQueryParameter($ajax_page_state), TRUE);
+      }
       $request->query->set('ajax_page_state', $ajax_page_state);
       $request->request->set('ajax_page_state', $ajax_page_state);
     }
-- 

not sure if it is necessary but there might be other ajax code floating around in contrib modules doing a similar thing to what we used to do?

Attached is another 9.5.x backport with the latest commits to MediaLibraryState and AjaxBasePageNegotiator, plus the above defensive bits of code to stop any potential PHP warnings being thrown. D9.5.x patch is now again dependant on the patch here https://www.drupal.org/project/drupal/issues/956186#comment-14991435

@commit That commit for Drupal\Core\Theme\AjaxBasePageNegotiator::determineActiveTheme is a better solution.

For the Drupal\Core\StackMiddleware\AjaxPageState how about something like this?

  /**
   * {@inheritdoc}
   */
  public function handle(Request $request, $type = self::MASTER_REQUEST, $catch = TRUE): Response {
    if ($request->request->has('ajax_page_state')) {
      $request->request->set('ajax_page_state', $this->parseAjaxPageState($request->request->get('ajax_page_state')));
    }
    elseif ($request->query->has('ajax_page_state')) {
      $ajax_page_state = $this->parseAjaxPageState($request->query->get('ajax_page_state'));
      $request->query->set('ajax_page_state', $ajax_page_state);
      $request->request->set('ajax_page_state', $ajax_page_state);
    }
    return $this->httpKernel->handle($request, $type, $catch);
  }

  /**
   * Parse the ajax_page_State variable in the request.
   *
   * Decompresses and decodes the json to return an array.
   *
   * @param mixed $ajax_page_state
   * This should be a string containing the compressed json query parameters.
   *
   * @return array
   */
  private function parseAjaxPageState(mixed $ajax_page_state) {

    if (is_string($ajax_page_state)) {
      $ajax_page_state = json_decode(UrlHelper::uncompressQueryParameter($ajax_page_state), TRUE);
    }
    else {
      /**
       * @deprecated ajax_page_state should be a compressed json encoded string
       * in all POST and GET in Drupal 10.2.0 and so the passed in variable will
       * be a string only in 11.x
       */
      trigger_error('From 10.2.0 Drupal\Core\StackMiddleware\AjaxPageState::handle() expects the ajax_page_state to be compressed using UrlHelper::compressQueryParameter() in all post and get requests, this check will be removed in drupal:11.x and generate a TypeError instead. See https://www.drupal.org/node/3389367.', E_USER_DEPRECATED);
    }
    return $ajax_page_state;
  }

In Drupal 10.2.x the code would allow the uncompressed ajax_page_state to pass through while logging the deprecated error. In Drupal 11.x the method could be change to private function parseAjaxPageState(string $ajax_page_state) and then it would throw a type error if the ajax_page_state variable is not the expected compressed string? Or 11.x could remain as it is now and just throw the TypeError from UrlHelper::uncompressQueryParameter()?

The new method parseAjaxPageState() to does all of the checking, then decompressing, then decoding to return the expected array to remove any duplicated code in the main handle() method and allows the adding of a single call to trigger_error()?

New version of the D9.5.x with your latest change to AjaxBasePageNegotiator::determineActiveTheme plus the parseAjaxPageState method to handle code not compressing the ajax_page_state variable attached.

@catch One thing with the commit https://git.drupalcode.org/project/drupal/-/merge_requests/4853/diffs?co...

It looks like the $ has gone awol in $ajax_page_state['theme_token']:

    if ($theme === $this->configFactory->get('system.theme')->get('default') || $this->csrfGenerator->validate(ajax_page_state['theme_token'], $theme)) {

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

@catch Media browser navigation is not working see video it's always in page 0 but if you filter by alphabetic order works.

I also adjust the patch to Drupal 10.1.x

@catch yes, you are right i have facets enabled and that causes the issue without console or php errors.

For me its RTBC.

CC failure in #91

Hiding patches to make it more clear.

We landed here, coming from #3380486: Extremely long Views AJAX query string triggers 403 in AWS. This compression solves our issue. RTBC for the MR, which is now green after rebasing.

Added a suggestion for the deprecation notice and a question.

Appears feedback has been addressed.

We do a lot of manual JSON encoding/decoding around this:

    $ajax_page_state = json_decode(UrlHelper::uncompressQueryParameter($ajax_page_state), 1);
    $ajax_page_state['libraries'] = $ajax_page_state['libraries'] . $fake_library;
    $ajax_page_state = UrlHelper::compressQueryParameter(json_encode($ajax_page_state));

Wonder if we should add helper methods to UrlHelper, e.g. [de]compressQueryArray(), which take/return an array instead of a string and handles the JSON encoding for us? However this wouldn't be a breaking change so we could do it in a followup.

Also not sure if the new argument to getDrupalSettings() is worth it, we don't need it here and unsure why anyone would need the compressed string; they can extract it from the content if they really need it? We shouldn't add API unless we have an actual use for it.

Other than these two points I think this is ready to go.

Thanks @catch! That addresses the concerns I raised in https://drupal.slack.com/archives/C1BMUQ9U6/p1698224910195289 and the concerns raised by @longwave in #104.

I updated the CR to reflect the new approach.

Looks good to me!

The new approach looks cleaner but there is a little bit of cleanup to do in the middleware compared to the previous version.

You're right, good catch! Applied the suggestion 👍

One more question about ajax.js, otherwise this looks ready.

Seems to have 1 open thread to revert some changes.

Reviewed the changes and added questions about code that seems unnecessary.

Committed b2a606d and pushed to 11.x. Also cherry-picked to 10.2.x. Thanks!

Is there any chance this would be rerolled for Drupal 10.1 also? We noticed the same issue in our staging environment which is behind a proxy. No issues in local.

I tried the latest 10.1 version of the patch from #91 but I get mixed results. It seems to fix the pagination issue of the views Ajax calls but exposed forms are broken. Previously also the exposed filters used GET with requests but now the pagination only loads the content with Ajax and exposed filters actually reload the page and pass the exposed values to the URL.

This seems to block our Drupal 10 upgrade pretty badly and 10.2 release schedule seems to be in December so there is a month of gap before this fix is released.

EDIT: We ended up resolving this issue in our own environment. The reason was actually our Varnish rules which had some extra security which prevented files ending with .module from being opened. The GET request actually contained this string and we received a 403 error from Varnish because of that. We ended up modifying our Varnish configs to ignore the /views/ajax path.

We had the same error on a Media pagination but on version 10.1.x.
Why this is not applied to that version?

We add a temporary patch if any had the same issue in the 10.1.x without the tests classes.

I had the same issue with Drupal 10.1.x and Media Directories and it has been resolved with #122.

#122 resolved same issue Drupal 10.1.6 and media_library view.

To my comment

We had the same error on a Media pagination but on version 10.1.x.
Why is this not applied to that version?

We got the response from Catch on the Slack contribute

because it's potentially a breaking change if a module is doing something strange with ajax_page_state.

Well, some drupal 10.1.x are reporting that the paginators are broken, so the "breaking change" was already introduced.

Thank you, Eduardo
The patch in #122 fixed the issue with Media Library and pagers.

Faced issues like #3401834: Fix Request-URI Too Long 414 for deep level 4 or 5+ AJAX requests
In number of projects
After upgrading to latest Drupal ~10.1.0

Hoping that the committed fix in 11.0.x, and 10.2.x to be back-ported to 10.1.x too

As explained in #125, because there is some potential for breaking custom code and contrib modules that depend upon ajax_page_state, there is no chance of this being committed to 10.1.x. However, sites can use patch #122 until 10.2.0 is released in a few weeks.

Noted;
Thanks, Damien, for the quick comment.
Happy with that, I will wait for Drupal ~10.2.0 stable tag release.
Doing more testing, after updating our custom ajax_page_state

While the patch in #122 definitely helped, the request is still going well over our Varnish limit size. Do we need to figure out how to let these requests through or is there some way to reduce this?? Loading the Media Browser and clicking through to a second page (with #122 applied) looks like this (2,390 chars not including headers):

https://dev.www.my-test-site.com/testing/views/ajax?ajax_form=1&_wrapper...

I wonder if we cannot pass this as a var in the private temp store, or something similar, instead of GET. It looks unusual big for something to be delivered in the URL. I know we’re doing it in other places (autocomplete?). But honestly, I haven’t looked into to see whether it’s doable

@catch
Gotcha. Would you suggest a new issue thread or piggy backing here? We were able to get around the Varnish issue but def still an ugly request. Also in debugging saw the request vars have a big duplicate section. All of this is in there twice:

media_library_opener_id=media_library.opener.field_widget
&media_library_allowed_types%5Bimage%5D=image
&media_library_selected_type=image
&media_library_remaining=1
&media_library_opener_parameters%5Bfield_widget_id%5D=field_media_image%3A-field_paragraph_band-0-subform
&media_library_opener_parameters%5Bentity_type_id%5D=paragraph
&media_library_opener_parameters%5Bbundle%5D=page_header
&media_library_opener_parameters%5Bfield_name%5D=field_media_image
&media_library_opener_parameters%5Bentity_id%5D=725
&media_library_opener_parameters%5Brevision_id%5D=797
&hash=MdCytfJWxVGpEfN1LYH6YKwhAuiPKz_o-u8JaIl7hyY

After applying #122, I appear to be getting a JS error after each AJAX call in Drupal.behaviors.fieldGroup:

Uncaught TypeError: Cannot read properties of undefined (reading 'Effects')

@beerendlauwers please open a separate issue with steps to reproduce, it looks like you at least have field_group module installed?

Still figuring out why for creating a new issue, but we've found that in some edge case TBD, it tries to decompress an already decompressed state, which ends up producing an ajax error because ajax_page_state[libraries] ends up being FALSE.

I suspect what I'm seeing is another variant of #3416700: Warning: Undefined array key 1 in Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies() after update to Drupal 10.2.2 and when views ajax is enable., so will follow-up there.

Ran into this on 10.1 and the patch at #122 helped.

Noting here that we have the Field Group module installed and I was unable to reproduce the Field Group errors mentioned above. Wondering if those errors are related to something else in the set up or maybe an issue with this patch and Field Group specifically on 10.2.

I vote that this should be reopened given that it was only closed due to inactivity and is still a major issue against 10.1 which is currently a supported minor version.

Hi,
this is still an issue, right? The views pager is not working on my site when AJAX is enabled. Tested with Drupal 10.2.0, 10.2.1, 10.2.2 and 10.2.3.

Edit:
This patch seems to fix the issue: https://www.drupal.org/project/drupal/issues/3384852#comment-15443093

The most likely cause of a broken pager is that you need to upgrade facets to the dev release. The latest stable release of Facets does not support the new pager AJAX.

+1 for re-opening