The user become "email_registration_JRABWYc2oY "

I'm not sure what could be causing this issue.

If you create a brand new site (maybe on simplytest.me) does this problem happen? If not, I suggest looking at the differences (configuration, code, etc.) between that brand new site and your site to figure out where the problem is.

I am also getting same problem. and i am trying to resolve the same.

Please used this :

function hook_user_load($users) {
$result = db_query('SELECT name,uid FROM {users} WHERE uid IN (:uids)', array(':uids' => array_keys($users)));
foreach ($result as $record) {
$users[$record->uid]->name = $record->name;
}
}

After this i am receiving the correct user name.

function createdbespoke_profile_user_load($users) {
$result = db_query('SELECT name,uid FROM {users} WHERE uid IN (:uids)', array(':uids' => array_keys($users)));
foreach ($result as $record) {
$users[$record->uid]->name = $record->name;
}
}

Hi,
Ealier no problems, it was based on part of the email name as described. Starting from today onwards, suddenly all new user registrations have become email_registration_XXXXYYYY. I'd only added a few rules last night, would rules modify the behaviours of this module ?
I did have tried to disable all the rules and test, still the same. How to further debug which had modifed its behaviour ? Thanks

Hi,
I traced out the cause, it's conflicting with User Revision https://drupal.org/project/user_revision , after disabling the module , everything is back to normal. Bug with Email Registration or User Revision ? Thanks

Having the same conflict with User revision module, when clicking on account confirmation email link

The patch from #8 is against user_revision. I suggest posting it to that module's queue.

For people having this problem, can you try messing with the weight of the module? Set email_registration's weight in the system table to be -1 or something and see if that fixes the problem?

I have done this too.

The bug does not fix by setting module weight, because user_revision uses hook_user_presave and hook_user_insert and Email registration only uses hook_user_insert.

Hi,
Thank you for the patch. Hopefully the maintainer of user revision will include it in the latest version. Often websites will encounter a serious breakdown after upgrade if those patches were not commited into the latest version.

Often I kept a long list of patched modules and checked if the patch was commited before upgrade. Thanks

Hi,
Also, I found that adding a Rules (Event -> Before Save User), if I happen to capitalize the User Name in the Rule, all new user registrations will become EMAIL_REGISTRATION_JRABWYc2oY , too

I have posted a possible alternative solution here
https://drupal.org/node/2163695

Moving the code from hook_user_insert to hook_user_presave allows the revision to be saved after the correct username is set.

Seems like this should be fixed in #2164213: Rules integration Create A New User Account ?.

This has been happening to me over the last several days, and I haven't figured it out. I'm not using User Revision, or any rule.

I'm still having this issue caused by the conflict by user revision.

The problem is that a new user revision is created on hook_user_presave() so the db update in email_registration_user_insert() doesn't trigger a new revision.
IMO this should be fixed in email_registration module rather then user_revision, creating a new revision when the username gets updated seems like the way to go for me.

@geertvd, are you using the patch in #2163695: Conflicting with Email Registration?

Can you clarify why you think this has to be solved in email_registration in stead of user_revision?

Sure the patch in #2163695: Conflicting with Email Registration works fixes the problem also, I just feel like email_registration is kind of bypassing the entity api by updating the the username in a query, so it seems logical to me that email_registration should also be responsible for triggering such a thing as a new user revision.

Granted this immediately creates 2 user revisions but technically that's also what's happening in the background.

Also the fix in #2163695: Conflicting with Email Registration is more dependent on the module's weight then the fix proposed in #16

I do not use User Revision so the patch does not apply to me but about a week ago, users who registered on my site had their account number attached to the name part of their email address.

JohnDoe@yada.com used to show as JohnDoe but now it becomes JohnDoe_1234 on newly registered accounts.

Could there be a conflict with the Automatic Entity Title module (disabling it doesn't fix the problem though?)

Any development of this issue?

@Triumphent can you start with a fresh test site (maybe using http://simplytest.me ) and document the steps necessary to start experiencing the problem?

I had forgotten that, earlier this month, I had updated the module from version 1.1 to version 1.3.
Reverting to the previous version (1.1) fixed the problem.

Just updated the module from ver. 1.1 to 1.2 and the problem reappears.
What's more, it had added this underscore followed by the account number to the name of users who had just registered under the previous version (1.1) (Accounts created by the Admin of course.)

The solution mentioned in #13 makes more sense to me than #16 so I've created a patch for it. Works on my case but I'll keep an eye on it on my setup. I'm not sure if this is the right way to fix the issue, though.

With Real Name module enabled the username is shown as email_registration_JRABWYc2oY

With Real Name module disabled the username is shown as [email local-part]_[user_id]

I reworked patch #23 to be smaller by reincorporating removed comments that I deem necessary as well as the removed check to make sure we won't change an existing account. I also added a general comment on why we don't use hook_user_insert().

This fixes the issue for me.

The reason was user_revision saving the revision in user_revision_user_presave() which is before email_registration_user_insert() is run, so the old temporary username is saved with the revision.

After switching to hook_user_presave(), it is ensured (or very likely), that email_registration_user_presave() runs before user_revision_user_presave() as user_revision sets a module weight of 99 (see user_revision_install()).

There might be other modules out there that rely on the username being final when using hook_user_insert(), so hook_user_presave() is the way to go.

The same problem exists in D8: #2935622: Switch to hook_user_presave() for setting username

Replaced

  if (!$account->is_new ||
    !empty($account->name) && strpos($account->name, 'email_registration_') !== 0) {
    return;
  }

with

  if (!$account->is_new ||
    (!empty($account->name) && strpos($account->name, 'email_registration_') !== 0)) {
    return;
  }

in patch #26.