Pager not working correctly in AJAX view with exposed filters

I have applied the patch #2 successfully and the issue is resolved. The views ajax is now filtering the specific content from entire view results instead from only specific page.
Adding screenshots for reference.
RTBC +1

@lobodacyril thanks for reporting this.

Yeah this does lead to weird results, but then people having that URL is a bit edge casey I think.

If you use Ajax to go to the last page, the page gets reset correctly, so there should already be logic for this somewhere, we should probably expand it to cover page numbers coming from the URL? Not sure hacking this into the Javascript is the best place to deal with this.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

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

Well, at least it doesn't break any existing test, that's positive.

We do need test coverage for this bug though, so setting back to needs work for that.

This is a patch for 10.2.x version.

I'm not sure this or the original behaviour works as expected when the query parameter is not the first entry, or the first query ends with a q or render.

I've provided some example test cases to showcase the behaviour here: https://playcode.io/1830989

const queryStrings = [
  'q=/path',
  'faq=should_not_be_affected',
  'myrender=should_also_not_be_affected',
  'q=/path&a=1&q=/second-path',
  'q=/path&render=value',
  'q=/path1&q=/path1&faq=true&dont_render=1&q=/path&render=render_value&page=1&final_value=1',
];
for (const queryString of queryStrings) {
  const output = [];
  output.push(queryString.replace(/q=[^&]+&?|&?render=[^&]+/, ''));
  output.push(queryString.replace(/q=[^&]+&?|page=[^&]+&?|&?render=[^&]+/, ''));
  output.push(queryString.replace(/(^|&)(q|render|page)=[^&]+/g, '').replace(/^&/, ''))
  console.log(output);
}

This might be potentially superseded by #2508796: Query string is appended multiple time after each AJAX request which now attempts to use a URLSearchParams object to remove those same values. But we may also look into using the updated regex provided instead, and leave that as a follow-up.

I also believe the render query parameter might be legacy code and no longer relevant in D9+, so can probably be removed since I can't find any references to it in core.

I created a merge request and added tests.

I updated the issue summary to the correct format.

Appears tests have been added

Added a nitpicky missing void return.

Verified the issue following the steps and that the MR addresses the issue.

Hiding unused MR.

@smustgrave, Applied mr changes are looking good to me, @
lobodakyrylon you can check it is good to go

Sorry folks, but this does need a title that better describes what is being fixed and be in proper English.

I think the points raised in #15 regarding the regex only working if the paramter is the first entry are still relevant.

@codebymikey do you want to open an MR to try your idea of removing.

Think maybe we should have test coverage for the points in #15.

As mentioned in the MR.
I have opened an MR using the latest changes introduced by smustgrave in #21, but with the alternate regex supplied by codebymikey in #15.

I have yet not added the test coverage as requested in #27.

Hi, I updated the test to cover scenarios with multiple query parameters in the request, specifically adding extra parameters like foo and q alongside the page parameter. This change ensures that pagination resets correctly when there are additional parameters in the URL, which is common in real-world cases.

Hi, I updated the test to simulate scenarios where multiple query parameters are involved in the request. Specifically, I added test cases that include extra parameters like foo and q alongside the page parameter. This was necessary because, in real-world scenarios, URLs often contain additional parameters, and I wanted to ensure that the pagination reset behaves correctly even with these variations.

I started by filtering content by title and confirming the correct result. Then, I tested the page with both foo and page parameters, applying the filter again to check that the additional parameters didn’t affect the pagination. Lastly, I included a case where both q and page parameters appear in different positions, ensuring the pagination resets as expected.

These updates help cover edge cases with query parameters, preventing issues with pagination and ensuring that the filtered content is returned correctly.

Additionally, I verified the fix in Drupal 11.x fresh install and attached before and after screenshots for reference.
Before:

After:

Kindly review the changes and please let me know if any further adjustments are needed. Your feedback and suggestions for improvements are greatly appreciated.

Thanks!

Before moving to review please make sure pipeline is passing and tags addressed.

Need to reconfirm whether this is still an issue in >= 10.3x since the merging of #3272629: Media Library widget display doesn't return to first page on applying filters

Rebased both MR's. Both pipelines all green. Test-only test fails as it should for MR !7485 but it passes as it should not for the other MR. Hiding that MR.

Now need to determine which of the 2x versions of the regex in the MR's is the 'correct' or 'best' version. Also need to manually test the issue (via UI) this issue in Drupal 11.x to see if it has been fixed in core RE: #34.

After the comment in #34 by codebymikey, I re-tested the 11.x branch and created the view as described.

Using the pager works fine as the pager also uses ajax.

The issue still exists if you visit the page:
/test?page=4 and then using the title filter. The page=4 URL slug remains after the filtering by ajax happens, so there are no results.

Looks like we can move to 'Needs review' after #39. Except perhaps #36: 'Now need to determine which of the 2x versions of the regex in the MR's is the 'correct' or 'best' version.'

Using:

composer config --json --merge extra.patches.drupal/core '{"Issue #3323574: Fixing regex": "https://git.drupalcode.org/project/drupal/-/merge_requests/9355.diff"}'

The view works and shows the articles with test in the name, even though the ?page=4 remains.

Also using:

composer config --json --merge extra.patches.drupal/core '{"Issue #3323574: Fixing regex": "https://git.drupalcode.org/project/drupal/-/merge_requests/7485.diff"}'

The view still works and shows the articles with test in the name, even though the ?page=4 remains.

Could do with a confirmation and a decision on which regex to use

Please confirm that this issue is about 'Pager shows empty/nonexistent page N after applying an exposed filter, so new result has less then N pages'?
And that it is an identical/similar problem to #2921519: Pager doesn't return to previous page when deleting the content from last page, which has a solution in core/modules/views/src/Plugin/views/query/Sql.php.

Should both use cases benefit from the same solution?

After enabling AJAX in a Views page in Drupal 11.x-dev version that lists Articles with an exposed Article Title filter, pagination behaves unexpectedly. The issue occurs under the following conditions:

1. The pager is set to display 10 items per page.
2. Navigating through multiple pages (e.g., reaching the 4th or 5th page)
3. Performing a search for a unique item results in a blank page instead of displaying the expected results.

A screen recording has been provided to demonstrate the issue.

https://www.drupal.org/files/issues/2025-03-05/pagination_search_issue_w...

Believe feedback has been addressed

Makes sense to do the quick fix here, the additional test coverage will ensure #2508796: Query string is appended multiple time after each AJAX request covers everything.

Committed/pushed to 11.x, cherry-picked to 11.1.x, 10.5.x, 10.4.x, thanks!

I merged this in #343535: Enable bookmarking of AJAX views and I believe this failing PaginationAJAXTest shows the new regex might cut query parameters that contain "page": https://git.drupalcode.org/issue/drupal-343535/-/jobs/4772946
For example '?items_per_page=gezgez&foo=bar'.replace(/q=[^&]+&?|page=[^&]+&?|&?render=[^&]+/, '') will return "?items_per_foo=bar".
Should I open a followup?

Hi @everyone,
I am using drupal 10.4.4 and still facing the paging issue when it loads the url than it shows the default 48 results and when i click on page 2 than i can see correct page result is coming for me, and when again going to first page number than it is showing the correct result, what ever is set in full pager count, and ajax is on for that views,
also I have tried the patch to apply, but no patch works for me.
please suggest.

For the record, I just noticed this issue on one of my client sites. It was on Core 10.4.5. I updated to Core 10.4.6 and I'm still seeing the same issue. I will report back once I figure it out. I wanted to add this comment in case anyone is looking through issue queues.