Pagination broken in admin for categories / tags / plugins

[ffffelix]

On list tables, the top pagination control includes an input field to type a desired page number, triggering navigation when the Enter key is pressed.

Since 6.7, #58479 introduced validation on the bulk actions submit button, which inadvertently blocks this pagination from functioning as expected on taxonomy lists and the plugins table. The form submission is prevented and an admin notice shown reading "Please select at least one item to perform this action on."

As a result, users are unable to navigate to pages directly via the input field. Instead, they must either navigate one page at a time using the pagination arrows or manually modify the URL parameter.

The bug only affects list tables where the search submit button is within a different <form> element from the pagination field. On other pages (e.g. posts, pages, comments) the pagination input field submits using the search submit button; so is unaffected by the JavaScript handler on the bulk actions submit button.

The bug is not present in 6.6.2.

Pages affected:

• /wp-admin/edit-tags.php?taxonomy=category
• /wp-admin/edit-tags.php?taxonomy=post_tag
• /wp-admin/plugins.php
• plus any custom taxonomies

Steps to reproduce:

1. Create enough tags to span multiple pages.
2. Navigate to /wp-admin/edit-tags.php?taxonomy=post_tag.
3. In the top pagination control, type "2" into the field and press Enter.

Expected behaviour:
Page 2 of the tag list loads

Actual behaviour:
The user remains on page 1, and the following error message is displayed:
"Please select at least one item to perform this action on."

[joedolson]

Thanks for reporting, @ffffelix! Confirmed the behavior, and that's definitely not what we want...

[joedolson]

The action applied for bulk actions is attached to any submit action on the containing form, and that form also includes the pagination input. Need to add an exception that ignores that input.

[im3dabasia1]

While working on the solution, I discovered two potential issues:

1 Page Number Resets During Bulk Action:

1. Add a sufficient number of categories.
2. Navigate to page 2 using the right arrow (>).
3. Click on the bulk action button.
4. You might notice that the number in the page input box changes to 1, but the data in the table still corresponds to page 2.

Video reference: ​https://jmp.sh/GfMgFCaU

2 Issue with Pagination Input on Version 6.6.2 (Before the changes in 6.7.1):

1. Add a sufficient number of categories.
2. Navigate to a page other than page 1.
3. Now, type "1" in the paged input box.
4. You might observe that the page will never go to 1, as it reloads the same page instead.

Video reference: ​https://jmp.sh/q1tBBSmt

Trac ticket: https://core.trac.wordpress.org/ticket/62534

### Description
This fix compares the initial and current page numbers to differentiate between a bulk action submission and a pagination action. If the page number has changed, it indicates a pagination submission, preventing the bulk action warning from triggering. This restores proper pagination functionality while ensuring the warning only appears for bulk actions when no items are selected.

### Screencast

​https://github.com/user-attachments/assets/c5e490dd-ed45-48f5-9be9-5dd6868715c2

Looks good beside the suggested change for the comment markup.

@apermo , Fixed this as per the suggestion.

[rishavdutta]

Test Report

Description

---

This report verifies whether the patch is working as expected or not: Pagination broken in admin for categories / tags / plugins

PR tested: ​https://github.com/WordPress/wordpress-develop/pull/7884

Test Environment

---

OS: MacOS
WordPress Version: 6.8-alpha-59274-src
PHP version: nginx/1.27.3
Database: mysqlnd 8.2.26
Theme: Twenty Twenty-Five (twentytwentyfive)

Test Results

---

The error is not yet resolved for the tag and category pages:

Category Page Pagination Recording:
​https://drive.google.com/file/d/1AjrD-7TT99tRV0nDLUjqD74q1WTbxyOZ/view?usp=sharing

Tag Page Pagination Recording:
​https://drive.google.com/file/d/1AjrD-7TT99tRV0nDLUjqD74q1WTbxyOZ/view?usp=sharing

[im3dabasia1]

Thank you, @rishavdutta.

In the video, the data still corresponds to page 2, but the value in the input box changes to 1. Inspecting the DOM reveals that the actual value remains 2, but the input box displays 1.

Initially, when clicking "Apply" under bulk actions, both the initial and current page numbers are the same, triggering the warning (this is considered a bulk actions request since the values are the same, so the warning is shown if no checkboxes are selected). However, on subsequent click, since the input box shows 1, the logic treats it as a pagination request, and the warning no longer appears.

If we can identify why the input box value changes and ensure it remains consistent, this issue can likely be resolved. I'd appreciate any guidance or suggestions on this.

PS: I checked on WordPress 6.6.2, and the page number was consistent after clicking on bulk actions from any other page, the input box would show the same number and would not change to 1.

The problem that causes manual entry of page 1 not to work was committed in https://core.trac.wordpress.org/changeset/38752; but there's no specific documentation about why that change was made. The props were attributed to @swisspidy, however; so I'm pinging Pascal to see if he remembers anything about exactly what that fix was for.

This change appears to still preserve the desired behavior from the original ticket , while allowing the manually typed page number to work.

_@swissspidy_ here 👋

Unfortunately I don't really recall the details of that change. I worked a bit on the edit tags form at the time, so it probably was something I encountered when testing that patch.

[jorbin]

I think the patch could use some additional testing to ensure that it fixes the issue and has no side affects

[jorbin]

Tested and reviewed the code, looks good to me.

[joedolson]

In 59727:

Administration: Fix pagination in categories, tags, and plugins tables.

Fix an issue introduced in [59134] that prevented manual entry of a page number in the pagination input field from navigating pages. Requiring validation of the bulk actions input also impacted other inputs nested in the same form.

Also fixes a pre-existing bug where it was not possible to navigate to page 1 using the input field.

Props ffffelix, im3dabasia1, apermo, rishavdutta, joedolson, swissspidy, jorbin, joedolson.
Fixes #62534.

[joedolson]

Reopening for backport to 6.7.

[jorbin]

[59727] looks good for backport to the 6.7 branch

[TobiasBg]

The added line

var initialPagedValue = document.querySelector( '#current-page-selector' ).value;

in /wp-admin/js/common.js now causes a JS script error on many screens (e.g. go to ​https://example.com/wp-admin/export.php), as there's no such DOM element on most screens.

This should get a check for existence of that DOM element.

[Mamaduka]

Seeing the same error as @TobiasBg in block editors.

[jorbin]

@Mamaduka @joedolson Would one of you be able to quickly review the patch to fix this issue?

[Mamaduka]

@jorbin, the patch looks good to me!

[joedolson]

Looks good to me, too! Marking for commit.

[TobiasBg]

Instead of this, would using ​https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/defaultValue be more reasonable?

[TobiasBg]

Also, is the second form.querySelector( '#current-page-selector' ) always guaranteed to have a value (inside the submit callback)?

[jorbin]

62534-defaultValue.patch looks good and I would support it but I'll defer to @joedolson as the owner of this issue on if that approach or the optional chaining one should go in.

[joedolson]

Either option looks good to me; I'll review and make a decision.

[joedolson]

Looking at this, and no, #current-page-selector is not guaranteed to always have a value, so making the verification dependent on that existing makes sense to me.

Uploading a very tiny tweak to the patch to chain the variable declarations.

[joedolson]

chain variable declarations

[joedolson]

In 59746:

Administration: Fix undefined element JS error in pagination handler.

Follow up to [59727]. Handle cases where the #current-page-selector is not present on the page to prevent a JS warning.

Props tobiasbg, mamaduka, jorbin, joedolson.
See #62534.

[jorbin]

In 59759:

Administration: Fix pagination in categories, tags, and plugins tables.

Fix an issue introduced in [59134] that prevented manual entry of a page number in the pagination input field from navigating pages. Requiring validation of the bulk actions input also impacted other inputs nested in the same form.

Also fixes a pre-existing bug where it was not possible to navigate to page 1 using the input field.

Reviewed by jorbin.
Merges [59727] and [59746] to the 6.7 branch.

Props ffffelix, im3dabasia1, apermo, rishavdutta, joedolson, swissspidy, jorbin, joedolson, tobiasbg, mamaduka.
Fixes #62534.