Administration: Fix Tags screen UI inconsistencies on add/delete

[SainathPoojary]

This PR fixes:

• Display the "No tags found." message immediately when the last tag is deleted via JavaScript.
• Hide .tablenav sections when no tags are present.
• Show .tablenav sections when a new tag is added via JS if none previously existed.
• Ensure pagination count is updated dynamically when tags are added or removed.

Trac ticket: #63372

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props sainathpoojary, joedolson, khokansardar.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[joedolson]

I made some refinements to this, but I'm in doubt whether it will be ready in time for 6.9. One issue was that the previous force push had overwritten some previous accessibility improvements; you'll want to be a bit more careful when merging prior changes in.

[itzmekhokan]

Thanks for pushing this forward — the client-side/PHP sync approach is the right direction, and the delete → empty-state → re-add cycle works well when the screen already has tags on load.

I dug into why the recent test reports (#20, and earlier #2/#8) still flag the empty-state and count behaviour, and it comes down to three concrete issues in updateTableNavCount(). I've left a single inline suggested change that addresses all three:

1. colspan="5" is hardcoded. Core renders the empty-state row with colspan="<?php echo $this->get_column_count(); ?>" (class-wp-list-table.php:1721) — total columns minus those hidden via Screen Options. 5 only matches the default Posts-tag table with every column visible; hide a column, or view a taxonomy/plugin with a different column set, and the “No tags found.” cell spans the wrong width.

2. The count is parsed with .text().match(/\d+/). Core prints it with number_format_i18n() (class-wp-list-table.php:1046), so on a site with more than 999 tags the value is grouped (e.g. “1,234 items”) and the regex reads 1. Stripping non-digits before parseInt() reads the real number regardless of the locale's separator.

3. Empty-state keys off “no rows on this page” instead of “no items at all”. $('#the-list tr').length === 0 is true as soon as the current page is emptied, so on a multi-page list deleting the visible rows shows “No tags found.” and hides the nav while the count still reads e.g. “15 items”. Keying on the running total (itemCount < 1) keeps them consistent.

Two smaller things folded in: reuse core's existing _n( '%s item', '%s items', … ) string (translators have already translated the %s form) instead of a new '%d item', and guard the decrement against a negative count.

Known remaining limitations (I believe acceptable to defer)

• Pagination page-links across the per-page threshold still aren't rebuilt — this matches your note in comment #13 that a bulk-add exceeding the current page size is an edge case and shouldn't block the improvement. Worth a follow-up, not this PR.
• Adding a tag to a screen that had zero tags on initial load can't fully populate the item count / bulk actions, because when has_items() is false core skips the bulk-actions markup and pagination() renders nothing, so .displaying-num isn't in the DOM to update (display_tablenav(), class-wp-list-table.php:1031). The delete-to-zero-then-add cycle works because that markup was rendered on load. Fully covering the from-empty case would need the add-tag AJAX response to return the pagination/bulk-action markup (or a WP_List_Table AJAX refresh) — a larger change I'd suggest tracking separately rather than expanding this PR.

[Copilot]

Pull request overview

This PR updates the Tags admin screen’s client-side add/delete behavior to keep the list table UI in sync without requiring a full page reload.

Changes:

• Update the “displaying-num” count when tags are added/removed via AJAX.
• Hide/show .tablenav and the search box when transitioning between empty/non-empty states.
• Show the “No tags found.” empty-state row immediately after deleting the last tag via JavaScript.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[itzmekhokan]

LGTM 👍

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.