Skip to content

Don't show a fake password on the site activation confirmation page when the user already exists#12652

Open
irozum wants to merge 3 commits into
WordPress:trunkfrom
irozum:fix/42389-wrong-password-manual-site-activation
Open

Don't show a fake password on the site activation confirmation page when the user already exists#12652
irozum wants to merge 3 commits into
WordPress:trunkfrom
irozum:fix/42389-wrong-password-manual-site-activation

Conversation

@irozum

@irozum irozum commented Jul 23, 2026

Copy link
Copy Markdown

When manual activation is enabled for additional site signups on a Multisite network (so a user who already has one site is required to confirm before an additional site is created), wpmu_activate_signup() still generates a brand-new password for the (already-registered) user and returns it in the result array. wp-activate.php then displays that freshly generated password on the confirmation page, even though it was never actually applied to the existing account — logging in with it fails and the user is confused about their real password.

This PR has wpmu_activate_signup() track whether the user already existed (it already computed this locally to decide whether to create a new user) and exposes it via a new user_already_exists key in the returned array. When the user already existed, the password key is now an empty string instead of the misleading generated one. wp-activate.php uses the new flag to show a message pointing the user at their existing username and password instead of a bogus one.

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

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Sonnet 5
Used for: Implementation, tests, and PR description. Reviewed by Igor Rozum.


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

Copilot AI review requested due to automatic review settings July 23, 2026 03:14
@github-actions

Copy link
Copy Markdown

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

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

@github-actions

Copy link
Copy Markdown

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.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a Multisite activation UX issue where wpmu_activate_signup() generated and surfaced a new password for users who already existed (e.g., activating an additional site), causing wp-activate.php to display a password that was never actually set on the account.

Changes:

  • Extends wpmu_activate_signup() to expose whether the activating user already existed via a new user_already_exists return key.
  • Ensures wpmu_activate_signup() returns an empty password when the user already exists to avoid surfacing a misleading credential.
  • Updates wp-activate.php to conditionally display either the password (new user) or guidance to use the existing account password (existing user).
  • Adds PHPUnit coverage for the new return behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
tests/phpunit/tests/multisite/wpmuActivateSignup.php Adds tests asserting password handling differs for existing vs new users during site activation.
src/wp-includes/ms-functions.php Adds user_already_exists to the activation return payload and blanks password for existing users.
src/wp-activate.php Hides the password on the activation confirmation page when activating an additional site for an existing user.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 1325 to +1329

return array(
'blog_id' => $blog_id,
'user_id' => $user_id,
'password' => $password,
'title' => $signup->title,
'meta' => $meta,
'blog_id' => $blog_id,
'user_id' => $user_id,
'password' => isset( $user_already_exists ) ? '' : $password,
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants