[robelsust]

Trac ticket: #66446

What

Prevents WordPress from automatically using an email address as a user's public display_name, nickname, or user_nicename when accounts are created with an email address as their username (user_login).

Why

Many sites and plugins (membership plugins, WooCommerce, SSO integrations, self-registration) register users whose user_login is formatted as an email address. Currently:

• display_name: Falls back to $user_login (john@example.com) if first/last names are absent. This gets exposed in post bylines via get_the_author(), RSS/Atom feeds (<dc:creator>), oEmbed data, and the public REST API (/wp/v2/users).
• nickname: Defaults to $user_login (john@example.com).
• user_nicename: Generates sanitize_title( $user_login ) (johnexample-com), exposing the user's email domain and local-part in author archive URLs (/author/johnexample-com/), sitemaps, and comment CSS classes (comment-author-{nicename}).
• user-edit.php & user-profile.js: Unconditionally offers user_login in the "Display name publicly as" select dropdown.

Because WordPress accounts allow authenticating with email addresses (since 4.5), exposing the email address as a public display name and URL slug presents both an account enumeration surface and a privacy violation (GDPR Art. 25(2) - data protection by default).

How

1. wp_insert_user() in src/wp-includes/user.php:

   • display_name & nickname: When $user_login is an email address (is_email( $user_login )) and no explicit names are provided, default to a neutral string (__( 'User' )) instead of the email address. Explicit first/last names or explicit display_name inputs still take precedence.
   • user_nicename: When $user_login is an email address and no explicit nicename is passed, generate an unexposed random slug ('user-' . strtolower( wp_generate_password( 8, false, false ) )) rather than slugifying the email domain into the URL.
   • Update Preservation: When updating an existing user ($update = true) where no new user_nicename is provided in $userdata, preserve $old_user_data->user_nicename so existing accounts and author links are never altered.
   • DocBlocks: Updated @since 7.2.0 changelog and @type descriptions for $display_name, $nickname, and $user_nicename.

2. src/wp-admin/user-edit.php:

   • Exclude $public_display['display_username'] from the "Display name publicly as" dropdown when is_email( $profile_user->user_login ) is true.

3. src/js/_enqueues/admin/user-profile.js:

   • In the blur.user_profile event handler, avoid re-adding display_username if the username contains an @ / email address.

4. Dedicated Unit Tests (tests/phpunit/tests/user/wpInsertUser.php):

   • Added canonical unit tests covering email login creation, explicit first/last name precedence, explicit overrides, unique nicename generation, preservation on updates, wp_create_user(), complex email addresses, and filter overrides (pre_user_display_name, pre_user_nickname, pre_user_nicename).

Testing Instructions

Automated Tests

Run PHPUnit tests across single-site and multisite:

# Single-site test suite
vendor/bin/phpunit tests/phpunit/tests/user/wpInsertUser.php

# Multisite test suite
vendor/bin/phpunit -c tests/phpunit/multisite.xml tests/phpunit/tests/user/wpInsertUser.php

# Code style check
vendor/bin/phpcs src/wp-admin/user-edit.php tests/phpunit/tests/user/wpInsertUser.php

Expected output:

• OK (11 tests, 42 assertions) on both single-site and multisite.
• 0 errors, 0 warnings on PHPCS.

Manual Testing

1. Navigate to Users > Add New (or use wp_create_user( 'member@example.com', 'password', 'member@example.com' )).
2. Create a user with Username = member@example.com and Email = member@example.com without providing First Name or Last Name.
3. Inspect the newly created user in Users > All Users and Edit User:
   • The user's Display name publicly as should show User, not member@example.com.
   • The user's author archive URL should be /author/user-{random}/, not /author/memberexample-com/.
   • Edit the user's First Name and tab out: the dropdown updates to include the new name without re-injecting the email address.
4. Create a user with a standard username (e.g. regularuser):
   • Verify that standard usernames continue to default display_name, nickname, and user_nicename to regularuser as before.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

Core Committers: Use this line as a base for the props when committing in SVN:

Props therssoftware, dpknauss.

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

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

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

[dknauss]

Thanks for the patch! I tested it locally on single-site and multisite, and the account-default changes passed.

I left you feedback on Trac suggesting the profile dropdown changes should not go into this initial fix: https://core.trac.wordpress.org/ticket/66446

[dknauss]

Some review observations:

The patch covers all three parts of the proposal on Trac #66446: no email fallback for display_name/nickname, a random user_nicename, and dropping the login from "Display name publicly as". Because REST name/slug, bylines, feeds, oEmbed and comment_author all read display_name or user_nicename, they're fixed downstream too.

A few notes:

On the neutral default

1. Every email-login account becomes "User". All such accounts share one byline and one comment name, so moderators, readers and author dropdowns (wp_dropdown_users() shows display_name) can't tell them apart. Could the default be unique but still anonymous, for example "User" plus the random part of the generated nicename (User k3j9x2ab)? The user ID isn't a good substitute: it isn't known before insert, and a sequential number leaks account counts.
2. __( 'User' ) is stored in the locale active at registration. A site can end up with "User", "Utilisateur" and "Benutzer" side by side, and changing the site language never updates them. Is that acceptable, or should the stored default avoid translated text?

Smaller notes

3. The new "preserve existing nicename on update" branch applies to all users, not only email logins (a direct wp_insert_user() call with an ID and a new user_login no longer rebuilds the slug). wp_update_user() merges existing data first, so most callers won't notice, but it may be better as its own change or with a test for the non-email case.
4. wp_generate_password() runs the random_password filter, so a plugin that filters passwords also controls author slugs. bin2hex( random_bytes( 4 ) ) or a slice of wp_generate_uuid4() avoids that, and the function_exists() guard probably isn't needed.
5. PHP uses is_email() while user-profile.js checks for @. A login like a@b (allowed by sanitize_user(), rejected by is_email()) is listed on page load and then removed when the JS rebuilds the list.

Test gaps

• Nothing asserts the downstream privacy outcome: REST name/slug, comment_author on a logged-in comment, feed author, author URL.
• No test for the profile screen options (PHP or JS).
• No multisite path (wpmu_create_user()).
• No test that an existing account whose display_name already is its email stays unchanged after wp_update_user().

[robelsust]

Thanks for the thorough and insightful review, @dknauss!

I've pushed updates addressing all of your observations:

1. Unique Anonymous Default:

   • Default display_name and nickname now use 'User ' . $suffix, and user_nicename uses 'user-' . $suffix, where $suffix = bin2hex( random_bytes( 4 ) ) (e.g., User 3a9f02c1 and user-3a9f02c1).
   • This ensures author dropdowns (wp_dropdown_users()), bylines, and comment listings remain uniquely distinguishable while preserving privacy, without leaking incremental account counts.
   • Removed the localized __( 'User' ) wrapper so stored database defaults don't create mixed-language drift across registrations.

2. Slug Generation:

   • Replaced wp_generate_password() with bin2hex( random_bytes( 4 ) ), ensuring plugin filters on random_password cannot alter author slugs or display names.

3. Nicename Preservation on Update:

   • Scoped the preservation check during $update strictly to email-login accounts ($update && is_email( $user_login ) && ! empty( $old_user_data->user_nicename )), leaving standard username updates untouched.

4. Profile Screen Alignment (PHP & JS):

   • In user-edit.php, #user_login now receives data-is-email="true" via is_email(), and user-profile.js checks this attribute before adding display_username to the public display options. This aligns PHP and JS behavior for usernames containing @.

5. Downstream & Edge-Case Test Coverage:

   • Added downstream privacy tests covering post bylines (get_the_author()), author URLs (get_author_posts_url()), authenticated comment author submission (wp_handle_comment_submission()), and the REST API (/wp/v2/users/{id}).
   • Added a Multisite test for wpmu_create_user().
   • Added a test verifying wp_update_user() does not overwrite legacy accounts whose display name was already an email.
   • Added a test verifying standard username nicenames remain intact on update.
   • Added tests covering public display options on the profile screen.

[dknauss]

Thanks for the update. I tested 53264a2 on disposable single-site and multisite installs using PHP 8.4 and SQLite. New accounts created through wp_create_user() and wpmu_create_user() got matching anonymous display-name, nickname, and slug suffixes. Public REST names, REST slugs, and author URLs reflected the anonymous defaults. wp_update_user() preserved an explicitly saved legacy email display name.

I found one update regression in both installs. Two calls to wp_insert_user() with the same existing ID and login, changing only the description and leaving the public name fields out, generated two different display names and nicknames. The author slug stayed fixed. An integration that calls wp_insert_user() directly can therefore change someone’s public byline every time it syncs their profile. Could we preserve the stored display name and nickname when those keys are omitted on update and add coverage for that case? The current legacy test exercises wp_update_user(), which merges stored fields before calling wp_insert_user().

One test gap remains on the profile screen. The new test builds its own array by repeating the condition from user-edit.php. It would still pass if the dropdown or its JS blur handler offered the email login. Could the test exercise the actual profile dropdown, both on initial render and after editing the nickname?

AI assistance: Yes. OpenAI Codex ran the PHP fixtures, inspected the patch, and drafted this review with me.

[robelsust]

@dknauss Thanks for the detailed review and catching that update regression!

I have addressed both items in commit 28fbdd3:

1. Preserve display_name and nickname on update when omitted:
   Updated wp_insert_user() in src/wp-includes/user.php so that when $update is true and display_name or nickname are omitted from $userdata, the existing values stored in $old_user_data are preserved. Added test_wp_insert_user_preserves_display_name_and_nickname_on_update_when_omitted() to ensure that successive wp_insert_user() calls (e.g. from profile sync integrations) keep the user's public byline, nickname, and slug intact.

2. Close profile dropdown test gap & extract core helper:
   Extracted the profile display name options computation from src/wp-admin/user-edit.php into a dedicated admin helper function wp_get_user_profile_display_name_options( $user ) in src/wp-admin/includes/user.php. user-edit.php now delegates directly to this helper, and test_profile_screen_public_display_options_omits_email_username() exercises the actual core function across initial creation, nickname edits, and first/last name combinations.

Both single-site (16 tests, 89 assertions) and multisite (17 tests, 93 assertions) test suites pass cleanly with 0 PHPCS errors.

[dknauss]

Thanks for turning this around so quickly. I tested a5fc071 on PHP 8.4 with MySQL 8.4. Tests_User_WpInsertUser passes on single site (16 tests, 89 assertions) and multisite (17 tests, 93 assertions), and the full user group passes on both. PHPCS reports no new warnings in the changed files. Both of my earlier points are addressed: repeated wp_insert_user() calls no longer regenerate the public name, and the dropdown options now come from one function that the test calls directly.

A few things before this is ready for a committer:

1. The update preservation now applies to every user, not only email logins. On trunk, a direct wp_insert_user() update that omits display_name or nickname resets both to user_login. With this patch, every account keeps its stored values instead. For a standard user with the login probestd, display name "Chosen Name", and nickname "ChosenNick", a direct update that only sets description resets both names to probestd on trunk and keeps them with this patch. I think that's the better behaviour, but it's a change to a long-standing default outside #66446's scope, and the @since note only mentions email logins. Could we either scope the preservation to email-login accounts, which is all the ticket needs, or keep it broad and call it out on the ticket and in the @since note so a committer can decide?

2. The JavaScript path is still untested. The new test covers the PHP options, but the blur handler in user-profile.js builds its own list, and that's where an edited nickname changes the dropdown. There's no QUnit coverage for user-profile.js yet, so this would be a new test file. One that sets data-is-email on #user_login, blurs #nickname, and checks that no option equals the login would close that gap. If that's more than this PR should take on, a note on the ticket describing how it was tested by hand would help.

3. New public API during beta. Trunk is at 7.2-beta5, so @since 7.2.0 on the new function, and on the wp_insert_user() changelog, probably needs to become the release this actually lands in. A new public function in wp-admin/includes/user.php is also an API commitment. Marking it private (an underscore prefix or @access private) would keep the testability without that commitment.

AI assistance: Claude ran the tests and the trunk comparison, and drafted this review with me.

[robelsust]

Thanks for the thorough review and catch, @dknauss! All three points are addressed in the latest commit:

1. Scoped update preservation to email logins:
   You're completely right that altering trunk's long-standing default for standard accounts is out of scope for #66446. In wp_insert_user(), preserving $old_user_data->display_name and $old_user_data->nickname when omitted from $userdata is now strictly guarded by is_email( $user_login ). This aligns with the existing user_nicename logic ($update && is_email( $user_login ) && ! empty( $old_user_data->user_nicename )). For standard non-email accounts (e.g. probestd), direct wp_insert_user() updates that omit name fields continue resetting to user_login as on trunk. We've added assertions for both cases in Tests_User_WpInsertUser::test_wp_insert_user_preserves_display_name_and_nickname_on_update_when_omitted().

2. Private API marker (_wp_ prefix):
   The helper function has been renamed to _wp_get_user_profile_display_name_options( $user ) with @access private in its DocBlock, keeping testability without committing to a permanent public API during beta.

3. JavaScript QUnit test & manual testing steps:

   • QUnit Coverage: Added a new test file tests/qunit/wp-admin/js/user-profile.js (and registered in tests/qunit/index.html). It tests that when data-is-email="true" is set on #user_login, blurring #nickname appends the updated nickname while strictly keeping the email address out of the #display_name dropdown options. It also verifies that standard accounts continue including their username.
   • Manual Testing Steps:
     1. Create a user where username is an email address (e.g., test.user@example.com).
     2. Navigate to Users > Edit User (user-edit.php?user_id=...).
     3. Verify the "Username" field has data-is-email="true".
     4. Inspect the "Display name publicly as" <select>: verify test.user@example.com is not present in the options (only the default User {suffix} nickname is present).
     5. Change the "Nickname" field to SuperTester and trigger blur (click or Tab outside).
     6. Verify the dropdown dynamically updates to include SuperTester while test.user@example.com remains excluded.
     7. Enter "First Name" and "Last Name", blur each field, and verify full name combinations appear in the dropdown without the email address.
     8. Repeat steps 1–7 with a standard non-email username (e.g., standarduser), verifying standarduser is included in the dropdown options as expected.

[dknauss]

Thank you, @robelsust. I tested 88e7d3c on PHP 8.4 with MySQL 8.4. The full user group passes on single site (1,490 tests) and multisite (1,553 tests), and Tests_User_WpInsertUser passes on both (16 and 17 tests). PHPCS reports the same warnings on the changed files as trunk, and nothing new.

All three points are addressed:

1. Update preservation is now limited to email logins. Both the nickname and display_name branches check is_email( $user_login ), the same guard the existing user_nicename logic uses. The new probestd assertions confirm that ordinary accounts reset to user_login as they do on trunk.
2. The helper is private. _wp_get_user_profile_display_name_options() is marked @access private, so there's no new public API.
3. The JavaScript path is tested. CI's QUnit job reports 718 assertions on this head, against 713 on trunk, so the five new assertions run and pass. The manual steps on the ticket cover the rest.

Two small things to note; neither is a blocker:

• The second QUnit test removes data-is-email from the shared fixture, and the first test's CustomNick option is still in the select. The tests pass in order. A fixture inside #qunit-fixture, which QUnit resets after each test, would keep them independent.
• @since 7.2.0 on the helper and in the wp_insert_user() changelog may need to change to the release this lands in. That's for the committer to decide, and this looks ready for a committer to me!

AI assistance: Claude ran the tests, compared the results with trunk, and I drafted this review with the results and draft details.