WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr> to match WP_Users_List_Table

[dd32]

WP_Users_List_Table::single_row() (used on per-site wp-admin/users.php) renders each user row with:

  <tr id="user-123">...</tr>

…but its network counterpart WP_MS_Users_List_Table::display_rows() (used on wp-admin/network/users.php) renders:

  <tr class="...">...</tr>

No id, no per-user anchor.

This makes it impossible to target a specific user row by ID on the network screen using stylesheets, JavaScript, or assistive-tech anchors, even though the per-site table supports it. Plugins that decorate / restyle specific user rows have to fall back to scraping the bulk-action checkbox (#blog_{ID}) and walking .closest('tr') — a brittle workaround.

Expected: <tr> on the network Users list carries id="user-{ID}" like the per-site list.

Actual: No row id at all.

## Summary

WP_Users_List_Table::single_row() (per-site wp-admin/users.php) renders each user row with id="user-{ID}". WP_MS_Users_List_Table::display_rows() (network wp-admin/network/users.php) does not — it emits <tr class="…"> with no row id at all.

This one-line change brings the network list in line with the per-site list.

## Why

Without a row id, plugin and assistive-tech code that decorates / anchors / focuses specific user rows on the network screen has to fall back to finding the bulk-action checkbox (#blog_{ID}) and walking .closest('tr') — brittle if the checkbox column is ever moved or renamed.

## Change

-            <tr class="<?php echo trim( $class ); ?>">
+            <tr id="user-<?php echo (int) $user->ID; ?>" class="<?php echo trim( $class ); ?>">

Additive — existing consumers of the class attribute are unaffected; new consumers gain the same stable hook the per-site list already exposes.

## Test plan

• [ ] Load wp-admin/network/users.php on a multisite install and confirm each <tr> carries id="user-{ID}" matching the user's ID.
• [ ] Confirm the per-site wp-admin/users.php is unchanged.

[johnjamesjacoby]

This makes sense and the diff looks great 👍

Setting myself as owner to commit soon, but any committer should if you’d like 💫

[alexodiy]

Tested PR ​#11600 on a multisite install against trunk.

Environment

• WordPress: trunk (multisite enabled)
• Environment: wordpress-develop Docker stack (npm run env:install with LOCAL_MULTISITE=true)
• Test users: 4 network users (IDs 1-4) with mixed roles

Test plan (per @dd32, comment:1)

1. Load wp-admin/network/users.php and confirm each <tr> carries id="user-{ID}".
2. Confirm per-site wp-admin/users.php is unchanged.

Results

Before patch (trunk):

On wp-admin/network/users.php, every <tr> in the users table renders without an id attribute. Bug confirmed.

After patch:

On wp-admin/network/users.php, every <tr> renders with id="user-{ID}" matching the user's numeric ID:

<tr id="user-1" class="alternate">
<tr id="user-2">
<tr id="user-3" class="alternate">
<tr id="user-4">

Per-site wp-admin/users.php is unaffected - the existing id="user-{ID}" continues to render as before (handled by WP_Users_List_Table, untouched).

Scenario	Before Patch	After Patch
network/users.php <tr> id	missing	id="user-{ID}" present
per-site users.php <tr> id	id="user-{ID}"	id="user-{ID}" (unchanged)

The (int) cast on $user->ID is a sensible defensive measure given WP_User::$ID is untyped (see inline discussion on the PR).

Patch looks correct and minimal. +1 for commit.

[manhar]

Tested in a multisite environment. The user rows in Network Admin now include the id="user-{ID}" attribute on the <tr> element, matching the behavior of the single site users table. Patch works as expected.