Send password reset action link not working on multisite

[christopherplus]

In a multisite installation while the quick action link "Send password reset" shows up when accessing users list (wp-admin/network/site-users.php), it doesn't send the email neither any admin notice appear when clicked. It simply redirects to the main multisite users screen (wp-admin/network/users.php).

[realloc]

Thanks for the report! I can confirm this is reproducible.

In WP_Users_List_Table::handle_row_actions() (class-wp-users-list-table.php), the "Send password reset" link is hardcoded to users.php?action=resetpassword, unlike the other row actions, which use the context-aware $url (set to site-users.php?id={site_id}& on multisite). On the network site-users screen, the link therefore points to network/users.php, which has no resetpassword handler. Result: no email, no admin notice, just a redirect to the network users list.

Possible fix: Build the reset link from $url (as remove already does) so it stays on site-users.php, and add a resetpassword case to site-users.php mirroring the existing handler in users.php.

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

[sukhendu2002]

Thanks for the report and the suggested direction. I picked this up because the issue remains reproducible on trunk and also affects the bulk password-reset action on the site-users screen.

PR: ​https://github.com/WordPress/wordpress-develop/pull/12808

The PR:

• Uses the context-aware $url for the row action.
• Adds resetpassword handling and notices to network/site-users.php.
• Shares reset processing between the regular and Multisite user screens.
• Handles invalid user IDs without a fatal error.
• Adds focused single-site and Multisite tests for the action URL, email dispatch, reset count, current-user skip, and invalid IDs.

The focused PHPUnit tests pass in both configurations, and all PR checks are currently passing. Review and feedback are welcome.

Nice fix — pulled the branch and confirmed both the row-action link and the bulk action work correctly now, in single-site and multisite, with the new tests passing in both configs. Also confirmed the err_admin_reset line removed from users.php was already dead code on trunk (it was unconditionally overwritten right after the loop), so that cleanup doesn't change behavior.

One small thing: in the new resetpassword case in network/site-users.php, submitting the bulk action with no users selected silently redirects with no admin notice (this mirrors users.php's existing behavior). But the sibling actions on this same screen — remove and promote — both show a "Select a user to …" notice in that case. Might be worth adding $update = 'err_resetpassword'; + a matching notice for consistency with the rest of the screen. Not blocking, just noticed the asymmetry.