[AbdiTolesa]

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

Summary

WP_Posts_List_Table::get_views() hides any status filter link (other than "All") whose post count is zero. WP_Comments_List_Table::get_views() had no equivalent, so "Pending", "Approved", "Spam", "Trash", and "Mine" were always rendered even at (0).

Per review feedback, applying the Posts list table's logic as-is doesn't fit the Comments screen, which is primarily a moderation queue rather than a plain content list:

• Hiding "Pending (0)" removes a reassuring "inbox zero" signal and could read as moderation being broken.
• Hiding "Approved (0)" removes the default working view.
• Hiding whichever status is currently selected (e.g. landing on ?comment_status=moderated from a stale notification, or ?comment_status=spam right after "Empty Spam") leaves the page with no visible "current" tab at all — no indication of what's being filtered.

Changes

• "Mine", "Spam", and "Trash" are hidden when their count is zero (unless currently active). "All", "Pending", and "Approved" always stay visible regardless of count. The currently active $comment_status is never hidden, even at zero count.
• Removed test_get_views_should_return_views_by_default (added for #42066), which asserted the old all-statuses-always-shown behavior this change intentionally revises.

How empty views are hidden: CSS class, not DOM omission

An earlier version of this PR had get_views() omit empty/non-active status entries from its returned array entirely, and had an AJAX moderation action re-render and replace the whole .subsubsub tab list over the wire so a status could appear/disappear live. Per review feedback, that re-render approach was replaced: re-rendering and swapping .subsubsub's HTML on every moderation action would destroy any DOM nodes, event handlers, or data a plugin may have attached to the existing view links — an architectural regression for plugin extensibility, even though it worked fine in isolation on a clean install.

Current approach:

• get_views() always returns every status key (never omits one); it separately records which ones are currently empty in a new $empty_views property.
• A new WP_Comments_List_Table::views() override (the base WP_List_Table::views() has no hook for this) adds an is-empty-view class to those views' <li> elements. A new CSS rule (.subsubsub li.is-empty-view { display: none; }) hides them — the markup itself always stays in the DOM.
• edit-comments.js's delAfter handler toggles that class on the relevant <li> (via a new toggleEmptyView() helper) after a spam/trash count changes, instead of replacing any markup. The currently active view is still never hidden, even at zero count.

Test plan

• php -l / node --check / npx eslint on all changed files — no errors.
• Ran Tests_Admin_wpCommentsListTable + Tests_Admin_wpPostCommentsListTable — 15 tests, 54 assertions, all passing.
• Ran Tests_Ajax_wpAjaxDeleteComment (--group ajax) — 5 tests, 84 assertions, all passing (back to its original count/shape, since the AJAX re-render approach and its test were reverted).
• Verified the "never hide the active view" test fails when that exception is removed from get_views(), and passes with it restored.
• Rebuilt edit-comments.js/.min.js and list-tables.css/.min.css/-rtl.css via grunt build:js --dev / grunt build:css --dev for local testing.

Fix: dangling "|" separator after a hidden trailing view

Spotted after the above: the | separator between views was attached as the last character inside the preceding view's own <li> (mirroring the parent WP_List_Table::views()), which assumed every view was actually visible. Now that empty views stay in the DOM (just CSS-hidden), a visible view followed only by hidden ones (e.g. "Approved" when "Spam"/"Trash" are both empty) still rendered its own trailing |, dangling with nothing after it. Fixed by attaching the separator as a leading marker on each view instead, skipped for hidden views and the first view that actually renders visible — so it disappears along with whatever's hidden around it, regardless of which combination of views are empty.

Fix: separator didn't appear when a hidden view became visible via JS

The previous fix baked the | separator into each view as a leading marker, computed from which views were empty at render time. That only held for the initial page load: when edit-comments.js later reveals a previously-hidden view by removing its is-empty-view class (e.g. "Trash" becoming non-empty after trashing a comment), that view's HTML never had a separator in it to begin with, so it rendered flush against the preceding view with nothing between them.

Fixed properly this time: the separator is no longer written as literal text in PHP at all. It's generated by CSS instead (::before on every non-first <li>, scoped to the Comments screen so other list tables — which still embed it as literal text and don't use is-empty-view — aren't affected). A hidden view's own separator is part of its own box, so it disappears and reappears together with the view itself automatically, regardless of which direction (initial PHP render, or a later JS toggle) its visibility changes in.

Refactor: share WP_List_Table::views() scaffolding instead of duplicating it

WP_Comments_List_Table::views() duplicated nearly all of WP_List_Table::views() (fetching/filtering views, the empty check, the screen-reader heading, the <ul> wrapper) just to customize how individual <li> elements are printed. Extracted that per-item printing into a new protected WP_List_Table::print_views( $views ) method that subclasses can override on its own — WP_Comments_List_Table now only overrides print_views(), nothing else. No behavior change for any other list table; this only moves existing code into its own method.

[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 abditsori.

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

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