Comments: "Mine" view count not updated via AJAX after moderation actions

[abditsori]

On the Comments screen (edit-comments.php), performing an AJAX moderation
action — Approve, Unapprove, Spam, Trash, Delete Permanently, or Undo —
live-updates several of the view tab counts in the DOM without a full page
reload. edit-comments.js's delAfter handler bumps:

• span.all-count
• span.pending-count (via updatePending())
• span.approved-count (via updateApproved())
• span.spam-count
• span.trash-count

span.mine-count is never touched by this code. As a result, after e.g.
trashing or deleting one of your own comments via the inline row actions,
the "Mine (N)" tab keeps showing the old count until the page is fully
reloaded — inconsistent with every other tab, which updates immediately.

Steps to reproduce:

1. Log in as a user who has left at least one comment on the site (comment's user_id matches the logged-in user).
2. Go to Comments in wp-admin. Note the "Mine (N)" count in the view tabs.
3. Click the "Mine" tab to filter to your own comments.
4. Use the inline "Trash" (or "Delete Permanently" / "Approve" / etc.) link on one of your own comments.

Expected: "Mine (N)" decrements immediately, matching how "All" and
"Trash" update.

Actual: "Mine (N)" stays at its old value until the page is reloaded.

Root cause: "Mine" uses the same status scope as "All" (approved +
pending comments; see WP_Comments_List_Table::get_views(), which queries
with no status arg and defaults to 'all'), just filtered to the
current user's own comments via user_id. The AJAX handler updates "All"
but has no way to know, client-side, whether the affected comment belongs
to the current user, so it was never extended to also update "Mine".

Suggested fix: render a data-comment-user-id attribute on each comment
row (WP_Comments_List_Table::single_row()), localize the current user's
ID to the admin-comments script, and in edit-comments.js compare the
two to decide whether to also bump span.mine-count alongside
span.all-count for the same pendingDiff/approvedDiff changes.

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

Summary

On the Comments screen, performing an AJAX moderation action (Approve, Unapprove, Spam, Trash, Delete Permanently, or Undo) live-updates several view tab counts in the DOM without a full page reload — edit-comments.js's delAfter handler bumps span.all-count, span.pending-count (via updatePending), span.approved-count (via updateApproved), span.spam-count, and span.trash-count.

The span.mine-count badge is never touched by this code, so after e.g. deleting one of your own comments via AJAX, the "Mine (N)" tab keeps showing the old count until the page is fully reloaded — inconsistent with every other tab.

"Mine" uses the same status scope as "All" (approved + pending comments; see WP_Comments_List_Table::get_views(), which queries with no status arg, defaulting to 'all'), just filtered to the current user's own comments. So it needs the same pendingDiff/approvedDiff updates that all-count gets, applied only when the affected comment belongs to the current user.

Changes

• WP_Comments_List_Table::single_row() now renders a data-comment-user-id attribute on each comment <tr>.
• The admin-comments script is localized with the current user's ID (adminCommentsSettings.currentUserId).
• edit-comments.js compares the acted-upon row's data-comment-user-id to the current user ID and, when they match, also updates span.mine-count alongside span.all-count for both pendingDiff and approvedDiff.
• Added test_single_row_includes_comment_user_id_for_mine_count_tracking to wpCommentsListTable.php.

Test plan

• [x] php -l on the changed PHP files; node --check and npx eslint on the changed JS file (no errors).
• [x] Ran Tests_Admin_wpCommentsListTable and Tests_Admin_wpPostCommentsListTable — 12 tests total, all passing.
• [x] Verified the new test fails against the unpatched class-wp-comments-list-table.php (no data-comment-user-id attribute) and passes with the fix.
• [ ] The JS behavior itself (live DOM update of span.mine-count after an AJAX action) isn't covered by PHPUnit — manually verified the logic by tracing delAfter in edit-comments.js, but a browser/QUnit check of the actual tab count updating live would be good before merging.