[huzaifaalmesbah]

Description

This is a refresh of #11777, the original PR by @alessioarzenton, scoped to the count fix and the separator it leaves behind.

wp.updates.deletePluginSuccess() only updates the counts of the groups Core knows about (Active, Inactive, Recently Active and the auto-update groups). A group added through the plugins_list filter, with its label from plugins_list_status_text (#60495), keeps its old count after a plugin is deleted, until the page is reloaded.

After the existing blocks, this goes through the other keys in settings.plugins. When a custom group holds the deleted plugin, its count goes down, and its tab is removed once it is empty. Core groups keep their own code paths, so nothing changes for them. The group key is escaped with $.escapeSelector() before it is used in a selector, since plugins_list keys can contain characters such as . or :.

Since custom groups come after the Core ones, they are usually the last view. WP_List_Table::views() puts the | separator inside every view but the last, so removing the last view left a trailing | on the one before it. After the views are updated, the trailing separator is now removed from the new last view, the same way wp.updates.decrementCount() has done for the Update Available view since r40025. This also covers Core views that are removed while last, which had the same leftover | before.

Changes from #11777:

• The move of the | separator from WP_List_Table::views() to CSS is left out. Core still hardcodes | in other .subsubsub lists (wp_network_dashboard_right_now() and the media upload filters), so the new CSS rule would show a double separator there. The leftover separator is removed in JavaScript instead, which leaves the markup unchanged.
• The group key is escaped in the selector.
• A QUnit test covers the count update, the removal of an empty group and the separator cleanup.

Testing Instructions

1. Add the snippet from the ticket description to a must-use plugin. It registers a "Demo Group" for plugins whose folder starts with a.
2. Install two plugins whose folder starts with a, and one that doesn't.
3. Go to Plugins > Installed Plugins. The tab reads "Demo Group (2)".
4. Delete one of the a plugins from its row actions.
5. Before this PR the tab still reads "(2)". With this PR it reads "(1)". Delete the other one and the tab is removed, with no | left after the view before it.
6. Check that Active and Inactive still go down as before.

QUnit:

npm run build:dev
npm run grunt qunit

The new test is "Deleting a plugin should update the counts of custom plugin groups" in tests/qunit/wp-admin/js/updates.js. It fails without the change to updates.js.

Screenshots

Deleting a plugin from the Demo Group view. Before, the tab and the item count keep the old numbers until a reload. After, both go down right away.

Deleting the last plugin of the last custom group. Without the separator cleanup, a | is left after the new last view. With it, the list ends cleanly.

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

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5.5
Used for: Code archaeology, brainstorming reproduction steps, and drafting initial diffs; root-cause diagnosis, implementation, and test verification were performed and verified by me.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

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

Props huzaifaalmesbah.

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

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

[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

• 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.