The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Updating the username when updating the user entity will be really helpful in some cases, especially when you implement hook_email_registration_name in your custom module and map a field with the username (email for example)
For the email_registration_username this is solved. But it's still an issue in the main module, see #23.
We may discuss to move the logic up into the main module eventually.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | update_username-3153809-6.patch | 3 KB | anas_maw |
| #2 | update-username_3153809_2.patch | 2.88 KB | anas_maw |
Issue fork email_registration-3153809
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
anas_maw commentedThis patch will keep the username synced when the user entity is updated.
Please note that in order to get this patch worked you need to apply the patch in #2935622-16: Switch to hook_user_presave() for setting username
Comment #3
anas_maw commentedComment #4
mrinalini9 commentedRerolled patch #2 as it failed to apply, please review.
Comment #5
anas_maw commentedPlease read carefully what I mentioned in #2, you just killed the patch functionality.
Please don't participate to get credits only, read the issue carefully, test the patch, and make sure that it's working as expected.
To get this patch works, you have to apply a previous patch in #2935622-16: Switch to hook_user_presave() for setting username
Comment #6
anas_maw commentedReroll the patch to work on latest dev version
Comment #7
anybody@Anas_maw: Totally makes sense to allow auto-updating the username, when the account is changed. But shouln't it better be called "Update username, if eMail address is changed"?
Any other change in the user account shouldn't affect the user name update, right?
Also I think we should discuss, if updating shouldn't be the default behavior, instead of having it the other way around, which would keep an outdated email address as user name then?
Comment #8
anybody@Anas_maw: As the related issue #2935622: Switch to hook_user_presave() for setting username is unresolved for years, I'd suggest we should not base this issue on that change, but handle them separately and merge things, once they are ready. Otherwise the chain will grow and the patches here have to depend on the ongoing other thread.
I'll prepare a MR that isn't depending on the other issue to make things easier. At least as long as there's no maintainer feedback and speedup in the issues.
Comment #12
anybodyComment #13
anybodyComment #14
anybody@Grevil could you please have a look, now, as you're deep into this area?
So we can probably finish this!
Comment #15
anybodyOkay the implementation here conflicts with the other issue, I think. We should choose one of the approaches, but first discuss what's best and expected.
Comment #16
grevil commentedDepending on the implementation, we settle on in #3193700: Allow Admin-users set username while user creation, we should either implement it or close this issue. If we settle on the prefixed username generation (e.g. email_registration_awnFqFb6af) updating the username doesn't make any sense.
Comment #17
grevil commentedComment #18
grevil commentedComment #19
grevil commentedComment #20
grevil commentedComment #21
anybody@Grevil: Isn't this fixed in 2.x? Or at least implemented like it just makes sense? ;) So we might close this fixed or works as designed for 2.x?
Comment #22
grevil commentedThis isn't fixed for the main module! We sync the mail address with the username in the submodule!
Comment #23
grevil commentedThis might still be relevant for the main module, as when we change our mail address from "abc@test.com" to "123@test.com", we might also want, that the username changes from abc to 123, but this should definitely have its own setting.
I would set this to minor for now, as the submodule implementation will cover 99% of all cases.
Comment #24
anybodyComment #25
anybodyNeeds reroll, tests and discussion for the right solution, eventually moving up the logics from the submodule.
Feel free to proceed here. Happy to review MR.
Comment #26
anybodyThe implementation has changed. If still relevant, it should be rethought and simplified. If no more relevant, we should close this won't fix. I guess it's an edge-case.