Allow users to login using either their username OR their e-mail address

+1 on concept.

I would definitely find this useful - even an option that allowed users to *only* login with their email address.

+1 / bump
Also for email only registration.

bumping to Drupal 7, and a +1 - this is increasingly standard behaviour on lots of different sites, and it would take little effort to implement.

+1 on this idea.

I agree with hickory that we should go further than login toboggan. We should remove $user->name from the authentication process using $user->mail alone.

A side benefit to this is that it might make life less complicated for folks who are working very hard on an idea to bring screen name functionality into Drupal: http://drupal.org/node/102679.

Shai
content2zero

The attached patch allows users to login with either their email address or username. It seems to work fine for me, but I'd like other people to review it and report anything they see wrong with it. It's possible I missed something or didn't test a feature that other people use.

It should be noted I saved the patch in notepad before uploading it.
I also wrote this with 7.x-dev in mind.

Haven't tested the patch, but it doesn't change any strings - the 'username' field would at a minimum have to be renamed to 'username or e-mail address'.

Additionally, why allow either value in the same field rather than making an extra 'e-mail' field and requiring either? I'm not sure which way is more common on the web and I think I've seen both.

You're absolutely correct. I should have changed the field to say "Username or email address". I should have also changed the error message when someone supplies an invalid email, user name, or password.

Attached is a new patch. The patch does the following: validates users on either user name or email address, changes the login for to say "Username / Email Address", changes the invalid login error message to "Sorry, unrecognized username, email address , or password", and it changes the field max size from 60 to 64 reflecting the max sized allowed for the mail field in the database.

I'm not 100% sure if I should change the form field name from name or not.

I save the patch in notepad2 in UNIX format at the recommendation of more experienced developers.

I forgot to change the status.

@catch - one textfield is less clutterring than two. so i like the approach proposed here.

but it is disruptive for modules that run validators and such to not know if they have been supplied an email or a password. i recommend that we add a #process or #element_validate to the name textfield and do the query if needed to populate name with a real username if needed. that way, #element_validate and #process run before validors and submit functions so those will be unaffected. hope this makes sense.

One other thing is we'd probably need some kind of check and/or upgrade path for username@example.com logins provided by drupal/site_network module. The chances of a conflict are pretty slim, but not impossible.

Thinking about 1 vs. 2 fields, where I've used sites that use two, I often find myself squinting to check if there's little red stars next to either, so I'd be pretty happy with a single field overall.

Single field is good: if there's an @, assume it's an email address, otherwise assume it's a username. That's what I've been doing with a separate module - it should work as @ isn't allowed in usernames.

hickory, @ is allowed in usernames. Try registering on groups.drupal.org with hickory@drupal.org

For some clients of us we had to implement this. Wouldn't it be better to provide a login method setting so people can choose how the users have to login:

Username,
Email Address,
Both

Let me know your thoughts about this.

+1

Subscribe

+1

Subscribe

Is this going to make it into d7 core?

See also: Email Registration

Nope; unfortunately it's a new feature and we closed Drupal 7 for features back in September.

to anyone trying to code this feature:

it's already fully working in the contrib module LoginToboggan. i encourage you to pull the code from there as a starting point, as it's worked perfectly for a long while, and it handles stuff that the earlier patches haven't thought yet to address -- like making sure one user can't change their username to another user's email address.

See issue #1359718: Allow password reset on account with the username matching another email; prevent registrations that match another account about the potential conflict between username and email -- it's already an issue as user/pass assumes they are distinct.

I agree that it'd be most useful if there was a setting for how a user can login. The reason for this is that email is becoming the preferred method, and I believe the more secure option (though I guess that's debatable -- reasoning is that usernames are displayed on the site so got one part of the login, whereas emails are not).

However, should core be supporting that option?

I throw up a sandbox moving the separating the functionality out of of logintoboggan (for various reasons), http://drupal.org/sandbox/hefox/1359748, where I did add that option via a required checkboxes with options username and email, that way can choice both or just one; does that make a sense, UI wise?

Could even add a variable_set in an update so that upgraded sites are set up for username only login.

I'll take a crack at an 8.x patch for this functionality this week.

Will work on this over the weekend.

This is a first pass implementation.

- Adds user login option to admin/config/people/accounts (options for username, email, or username or email.
- Depending on option modifyies user_login form and user_login_block form
- modifies validation, validates e-mail with valid_email_address(), uses current validation on username (renamed validation funtion from user_login_name_validate() to user_login_username_validate()
- If UUSER_LOGIN_USERNAME_OR_EMAIL is selected then tests validity of email, if not a valid email assumes input is a username
- Modifies authentication functions to authenticate based on option set by admin

I wonder if we need an option for this at all? Can't contrib provide a module, for those sites that want to disallow logging in with username and e-mail.

IMHO, this feature is more than welcome for community web site builders where you maybe will not be using username at all - and especially not for logging in. So, if you want to make Drupal more easier to use for building above mentioned sites, this is MUST.

Also it would be great to have (hidden API) option to turn off uniqueness of usernames, but this should be follow up issue..

I'm in favour of the option as it allows email login only, which is popular, and allows upgrade from 7 sites that are username login.

I'm curious what the rational behind making the setting an single select instead of required check boxes? It seems to add more complexity (needing defines instead of checking what's in an array of options) and would be unflexible for contrib modules adding options in (for example, there's a login via UID module).

Drupal ui standards: http://drupal.org/ui-standards (didn't see anything that would suggest what the proper answer is, though I really think checkboxes matches better).

Needs work do to minor code style.

+    '#type' => 'select',
+  '#title' => t('What credentials can users use to login?'),
+    '#options' => arra

> + '#title' => t('What credentials can users use to login?'),

Also, nothing in UI guidelines, but I think we generally avoid labels being written as questions.

@hefox

I'm curious what the rational behind making the setting an single select instead of required check boxes? It seems to add more complexity (needing defines instead of checking what's in an array of options) and would be unflexible for contrib modules adding options in (for example, there's a login via UID
module).

My rationale is that it is usually easier to get a change commited that has minimal impact on current UI, and my feeling was that a select was less impactful than several checkboxes. I do like the checkbox approach. [ ] e-mail [ ] username, but at least one would need to be checked. Tagging 'needs usability review'.

I don't really see how either approach is easier for extensibility, static enum equivalents, or an array of options, neither of these are the bottleneck of complexity when extending the log in validation / authentication logic. I do, however, agree that to avoid conflicts between multiple modules that attempt to extend the options (login_by_uid and login_by_foo modules), that it would be easier for the options to be represented in code as strings ('email', 'username', 'uid', 'foo') rather than integers ('1', '2', '3', '3'), where contrib modules could choose conflicting integers more easily than conflicting strings.

@joachim

+ '#title' => t('What credentials can users use to login?'),

Also, nothing in UI guidelines, but I think we generally avoid labels being written as questions.

If anyone has suggestions for changes to the UI strings anywhere in the patch please let me know. I admit that selecting UI strings is not one of my strengths.

Would like usability review on questions in #27 and #29

My suggestion is:

'#title' => t('Login credentials'),
'#description' => t('The details a user may use to identify themselves'),

New patch takes into consideration comments in #28, #29, #32. Also takes into consideration part of #27 by making static values strings and not integers to make it less likely that modules will provide options with conflicting values.

Sticking with the select element for now, but we can further discuss changing to checkboxes if there is consensus.

+    '#title' => t('Login credentials'),
+    '#description' => t('The details users may use to identify themselves.'),

+++ b/core/modules/user/user.module
@@ -16,6 +16,21 @@ const USERNAME_MAX_LENGTH = 60;
+const USER_LOGIN_USERNAME_ONLY = 'username_only';

If we're using strings, then do we need constants? The machine strings should be understandable as they are.

0 days to next Drupal core point release.

Using constants w/ strings makes things easier, particularly during development, when the string changes. I don't know if we hav a code standard for this, but I always prefer to use constants for the ease of changing values.

I have one usability suggestion to make: make passwords optional as well.

This would involve replacing the "request new password" user tab with "connect through email" tab. Users receive the login token in their email account, and they keep it going as long as the cookie doesn't expire. But we would need to remove all suggestions of updating passwords.

Passwords are dangerous - nobody remembers them or they use repeat passwords that are easy to compromise across sites.

That sounds like a totally new feature request. Could you file a separate issue for that?

Sorry, I want to review this - but it would require a screenshot, can anyone take care of that?

I applied the patch to a fresh drupal 8 git install and tested. I was able to login with my email address once I enabled the feature on the user settings admin screen.

Please see the attached screenshot for the how the login and settings screen look.

Just installed patch on fresh d8 install.

Works really nicely, simple to administrate.

I tested the 'username or email address': i can login with either, if i get either wrong it throws the correct errors

tested just email address: i can login with email address, if i try to log in with name it throws the correct error

all looks great to me.

+++ b/core/modules/user/user.moduleundefined
@@ -1210,12 +1225,32 @@ function user_login_block($form) {
+  switch (variable_get('user_login_name_option', USER_LOGIN_USERNAME_ONLY)) {
+    case USER_LOGIN_USERNAME_ONLY:
+      $form['name'] = array('#type' => 'textfield',
+        '#title' => t('Username'),
+        '#maxlength' => USERNAME_MAX_LENGTH,
+        '#size' => 15,
+        '#required' => TRUE,
+      );
+      break;
+    case USER_LOGIN_EMAIL_ONLY:
+      $form['name'] = array('#type' => 'textfield',
+        '#title' => t('E-mail address'),
+        '#maxlength' => EMAIL_MAX_LENGTH,
+        '#size' => 15,
+        '#required' => TRUE,
+      );
+      break;
+    case USER_LOGIN_USERNAME_OR_EMAIL:
+      $form['name'] = array('#type' => 'textfield',
+        '#title' => t('Username or e-mail address'),
+        '#maxlength' => EMAIL_MAX_LENGTH,
+        '#size' => 15,
+        '#required' => TRUE,
+      );
+      break;

Several of these are the same - could we set some defaults then just change the relevant pieces in the switch?

Also it'd be good to clean up the '#type' being on the same line as the array declaration, I'm sure that's user module violating coding standards.

+++ b/core/modules/user/user.moduleundefined
@@ -2070,9 +2126,35 @@ function user_login_default_validators() {
+ * A FAPI validate handler. Depending on user_login_name_option, delegates
+ *   validation to user_login_username_validate() and valid_email_address().
  */
 function user_login_name_validate($form, &$form_state) {
+  if (isset($form_state['values']['name'])) {
+    switch (variable_get('user_login_name_option', USER_LOGIN_USERNAME_ONLY)) {

This should probably be renamed? Not sure what to though...

+++ b/core/modules/user/user.moduleundefined
@@ -2096,7 +2178,23 @@ function user_login_authenticate_validate($form, &$form_state) {
-    $account = db_query("SELECT * FROM {users} WHERE name = :name AND status = 1", array(':name' => $form_state['values']['name']))->fetchObject();
+    $account = FALSE;
+    switch (variable_get('user_login_name_option', USER_LOGIN_USERNAME_ONLY)) {
+      case USER_LOGIN_USERNAME_ONLY:
+        $account = db_query("SELECT * FROM {users} WHERE name = :name AND status = 1", array(':name' => $form_state['values']['name']))->fetchObject();
+        break;
+      case USER_LOGIN_EMAIL_ONLY:
+        $account = db_query("SELECT * FROM {users} WHERE mail = :mail AND status = 1", array(':mail' => $form_state['values']['name']))->fetchObject();
+        break;
+      case USER_LOGIN_USERNAME_OR_EMAIL:
+      if (valid_email_address($form_state['values']['name'])) {
+        $account = db_query("SELECT * FROM {users} WHERE name = :name AND status = 1", array(':name' => $form_state['values']['name']))->fetchObject();
+        }
+        if (!$account) {
+        $account = db_query("SELECT * FROM {users} WHERE name = :name AND status = 1", array(':name' => $form_state['values']['name']))->fetchObject();
+        }
+        break;

This doesn't look right. the USER_LOGIN_USERNAME_OR_EMAIL hunk is running the same query twice against name, shouldn't it be checking the e-mail address the first time? If that's the case, we should also add test coverage for this.

Also resetting tags now there's a screenshot.

I think we should look at shamelessly stealing code from LoginToboggan, which already has this feature, and has had a lot more eyeballs on it over the years.

@ kscheirer:
email registration seems a more relevant solution.

Looks like we are applying the standard here, so good from my point of view

Updated patch for config changes, combined some stuff to cut down on the duplicate/similar logic, and added some tests.

+++ b/core/modules/user/config/user.settings.yml
@@ -1,5 +1,6 @@
+user_login_name_option: username_only

If you're talking about an option like the variable name says, I would expect its value to be ON/OFF or TRUE/FALSE. Given that the values are explicit, why not call that variable a method? something like user_login_method or user_login_name_method.

+++ b/core/modules/user/lib/Drupal/user/Tests/UserLoginTest.php
@@ -21,6 +21,33 @@ public static function getInfo() {
+   * Test that login credientials work. ¶

typo and ending white space

updating issue summary and adding tags.

updated screenshots would be helpful to make sure things have not changed.

interdiff and tests only patch would help

marking it needs work to get this ready for a committer to look at (like updated screenshot and tests only patch for the testbot).

I think at least the white space #46 should be addressed.

some of these tasks are Novice

Here's screens, interdiff and updated patch. This is ready to fly imo.

#49: 111317-49.patch queued for re-testing.

The use of a SELECT seems a bit weird UI.

Why not checkboxes, and tick both to mean 'Username or e-mail address'?

checkboxes would make the submission and form logic a bit more convoluted. Maybe radio buttons might be better ?

But then how would you pick both email and username?

It will indeed make code more complicated, but that's because the way the user will think about this and the way the system thinks about this are completely different unfortunately.

Take a step back and consider that this is kinda wacky UI:

() A
() B
() A or B

checkboxes... we would not want someone to uncheck both.

what are the admin choices:
() username
() email or username

are we adding also to allow
() email
where username is not used for logging in, and force using email address? (answering my own question:) I looked at the patch and yes.

I suggest next steps,

• lets use radio buttons
• get a screenshot of that, even though it is strange.
• file a small follow-up issue to refactor the code to allow using checkboxes.

@swentel http://drupal.org/node/1859584 has some hints for how to get a screenshot with a select dropped down so we can see all the choices in it.

> checkboxes... we would not want someone to uncheck both.

Make them required :)

+++ b/core/modules/user/lib/Drupal/user/Tests/UserLoginTest.phpundefined
@@ -22,6 +22,33 @@ public static function getInfo() {
+  /**
+   * Test that login credentials work.
+   */
+  function testLoginByEmail() {
+    $account = $this->drupalCreateUser(array());
+
+    // Login via name.
+    $this->drupalLogin($account);
+    $this->assertFailedLogin($account, NULL, TRUE);
+
+    // Login via email only.
+    config('user.settings')
+      ->set('user_login_method', USER_LOGIN_EMAIL_ONLY)
+      ->save();
+    $this->drupalLogin($account, TRUE);
+    $this->assertFailedLogin($account);
+
+    // Login via name or email.
+    config('user.settings')
+      ->set('user_login_method', USER_LOGIN_USERNAME_OR_EMAIL)
+      ->save();;
+    $this->drupalLogin($account, TRUE);
+    $this->drupalLogin($account);

a comment at the beginning with what the default user login method is might help clarify.

I need to look more closely at this to understand it.

I think the last case here, with the OR method should test both logging in with username and email. Maybe that is what the TRUE option to drupalLogin is doing.

We dont need an assert it was successful?

Hm. actually, I think I get it. I might have a patch for improving the comments here later. (not blocking this)

I'll update the issue summary remaining tests to remove the task to add tests since they are there. :)

Updated issue summary to add remaining tasks to make it easier for new people

I'm thinking something like:

    // Login via name, the default method.
    // Using email should fail.
    $this->assertFailedLogin($account, NULL, TRUE);
    // Using username should pass.
    $this->drupalLogin($account);

    // Login test with email only method.
    config('user.settings')
      ->set('user_login_method', USER_LOGIN_EMAIL_ONLY)
      ->save();
    // Using email should pass.
    $this->drupalLogin($account, TRUE);
    // Using username should fail.
    $this->assertFailedLogin($account);

    // Login via name or email method.
    config('user.settings')
      ->set('user_login_method', USER_LOGIN_USERNAME_OR_EMAIL)
      ->save();;
    // Using email should pass.
    $this->drupalLogin($account, TRUE);
    // Using username should pass.
    $this->drupalLogin($account);

added comments (need to check the api for drupalLogin and assertFailedLogin)
and switched the order of the tests in the first group so each group is: 1) email 2) username.

I can do the patch for this later, recording notes because I'm interrupted for now. It's ok if someone wants to do it before I get back to it.

[edit: need better worded comments. Like using username consistantly (not name) and e-mail instead of email I think...]

I'm confused. Looking at the code, I expected a second parameter to WebTestBase drupalLogin
http://api.drupal.org/api/drupal/core%21modules%21simpletest%21lib%21Dru...

doh! right, this patch changes that. *grin*

similar with assertFailedLogin
http://api.drupal.org/api/drupal/core%21modules%21user%21lib%21Drupal%21...

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.phpundefined
@@ -621,16 +621,18 @@ protected function checkPermissions(array $permissions, $reset = FALSE) {
+   * @param $by_email

+++ b/core/modules/user/lib/Drupal/user/Tests/UserLoginTest.phpundefined
@@ -139,10 +166,15 @@ function testPasswordRehashOnLogin() {
+   * @param $by_email

should have type (bool)
http://drupal.org/node/1354#types

+++ b/core/modules/user/lib/Drupal/user/Tests/UserLoginTest.phpundefined
@@ -157,7 +189,22 @@ function assertFailedLogin($account, $flood_trigger = NULL) {
+          break;
+        case USER_LOGIN_EMAIL_ONLY:

case looks like should have blank lines.

+++ b/core/modules/user/user.moduleundefined
@@ -1312,12 +1328,26 @@ function user_login_default_validators() {
- * A FAPI validate handler. Sets an error if supplied username has been blocked.
+ * A FAPI validate handler. Depending on user_login_method, delegates
+ * validation to user_login_username_validate() and valid_email_address().

needs to be one line.

Also, I dont understand this comment and user_login_username_validate() is not a function I could find anywhere.

-------------------

patch attached.

needs work to make required, 2 checkboxes:
E-mail
Username

thanks @joachim

#60: drupal-allow_users_to_login_using_either_their_username_OR_their_e-111317-60.patch queued for re-testing.

yep. enabling testing locally, and then going to the testing list whitescreens.

I checked each of the files effected by this patch for php syntax errors and did not find any, still looking for cause.

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.phpundefined
@@ -621,16 +621,18 @@ protected function checkPermissions(array $permissions, $reset = FALSE) {
-      'name' => $account->name,
+      'name' => $by_email ? $user->mail : $user->name,

Shouldn't this be $account instead of $user?

yeah, that looks like it should be account.

I tried tests locally with that change, and still whitescreen.
Then I started removing the tests...

How do people debug a situation like this?

WSOD can be generally be debugged by looking at your PHP and Server logs.

It's kind of buried in the testbot report details, but way at the bottom there's:

[00:22:29] Command [/usr/bin/php ./core/scripts/run-tests.sh --concurrency 8 --php /usr/bin/php --url 'http://drupaltestbot659-mysql/checkout' --keep-results --all 2>&1] failed
Duration 1 seconds
Directory [/var/lib/drupaltestbot/sites/default/files/checkout]
Status [255]
Output: [PHP Fatal error: Class 'Insert' not found in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/rest/lib/Drupal/rest/Tests/RESTTestBase.php on line 215

Fatal error: Class 'Insert' not found in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/rest/lib/Drupal/rest/Tests/RESTTestBase.php on line 215].

does that help at all?

@larowlan helped me during core office hours to figure out that REST in extending drupalLogin!
So we have to add the arg there too.
grep -R "function drupalLogin" *
shows just that one to fix.

patch coming soon.

this fixes #65, removes a newline that was extra, and attempts to fix the whitescreen by adding the 2nd argument to the REST drupalLogin.. (but it still whitescreens).

I followed http://geek.michaelgrace.org/2011/08/xdebug-cachegrind-and-mamp-on-mac-osx/ to set up Xdebug, and while my info.php says it's enabled, I dont get any more information on the whitescreen.

oops. that was an earlier interdiff. here is the correct one (just shows that newline change)

ah, the function args need to be *identical* (thanks @larowlan)

no whitescreen and the user login test passes locally.

next, to change the radios into required checkboxes

here was a start at converting the select to checkboxes (where checking one would be required).

I could not find another example in core of doing that... and I could not figure out if it was possible.

well, here it is as radios.

Interesting. I must test it !

Code looks great.
Tests look great.
Works as advertised when testing manually.
Great feature.
Want to see this in Drupal 8?
Help us get thresholds down....see http://buytaert.net/code-freeze-and-thresholds for more information on why this might still sneak in....

Did a quick reroll. Looks like #1757098: Add types to return values of webTestBase methods was modifying code nearby.

back to rtbc
since that was just a re-roll.

#79: 111317-name-or-mail-79.patch queued for re-testing.

#79: 111317-name-or-mail-79.patch queued for re-testing.

+++ b/core/modules/user/user.moduleundefined
@@ -1285,12 +1301,30 @@ function user_login_default_validators() {
+      if ($account = db_query("SELECT * FROM {users} WHERE mail = :mail", array(':mail' => $name))->fetchObject()) {
+        $name = $account->name;

This could just be SELECT name then fetchField().

+++ b/core/modules/user/user.moduleundefined
@@ -1313,7 +1347,15 @@ function user_login_authenticate_validate($form, &$form_state) {
+    $credentials = config('user.settings')->get('user_login_method');
+    if ($credentials != USER_LOGIN_USERNAME_ONLY && valid_email_address($form_state['values']['name'])) {
+      $account = db_query("SELECT * FROM {users} WHERE mail = :mail AND status = 1", array(':mail' => $form_state['values']['name']))->fetchObject();
+    }
+    if (!$account && $credentials != USER_LOGIN_EMAIL_ONLY) {
+      $account = db_query("SELECT * FROM {users} WHERE name = :name AND status = 1", array(':name' => $form_state['values']['name']))->fetchObject();

First time reading this through I was concerned about usernames that look like e-mail addresses but aren't - such as those which the old Drupal module used to create (killes@www.drop.org is one), but since this falls back to name in the case that email fails that seems fine.

However I'm concerned about the following case:

User A has the username foo@example.com

User B has the e-mail address foo@example.com

If User B is blocked, then won't user A be locked out of the site?

This could also happen for very old sites where someone's registered more than once.

Once you've registered an account there's no requirement for e-mail validation, so in the case of killes someone could register with their own e-mail, change it to killes@www.drop.org, post some spam to the core issue queue, and now killes can't log in.

At a minimum, I think we need validation when new users register that their username matches neither an existing username nor an existing e-mail address.

For sites with accounts in this condition there's not a great deal that can be done but maybe a warning in the upgrade process?

Tagging with security.

Nice catch.

#83:

At a minimum, I think we need validation when new users register that their username matches neither an existing username nor an existing e-mail address.

This validation is part of the patch at #1359718: Allow password reset on account with the username matching another email; prevent registrations that match another account.

[edit:]
Moved comment to a new issue #2014185: Check usernames that are email addresses more rigidly, only allow if matches email. Would be very grateful for opinions on that!

#79: 111317-name-or-mail-79.patch queued for re-testing.

The current user.module diverged too much from the original code from March.
Function user_login_name_validate was removed and I think the validation system has changed.
This would need to be rewritten.

the missing interdiff was done. updated remaining tasks

This patch needs to be rewritten now. Most of the hunks no longer apply.

Yeap if it's done then I can turn off one more module. Maybe module developers could help here (this one I'm using all the time - https://drupal.org/project/logintoboggan)?

Marked #2192125: Allow users to log in with e-mail as username a duplicate of this one here.

Can we please move forward here? It's 2014 and I don't want to remember my username for every site.

Rewrote the patch. Just applying the same logic to the new codebase API.

+++ b/core/modules/user/config/install/user.settings.yml
@@ -1,5 +1,6 @@
+user_login_method: username_only

I think we have to update user.schema.yml as well.

the only pending thing

At a minimum, I think we need validation when new users register that their username matches neither an existing username nor an existing e-mail address.

Above comment is quoted from #83.
I just saw #85 so this issue is postpone on #1359718: Allow password reset on account with the username matching another email; prevent registrations that match another account.

@ivanjaros; nope, not even close to that record.

rerolled #99 on latest dev

Hello, login toboggan for Drupal 8 isn't working and I think that email and facebook login are essential in 2016, so is it going to be in core ?

Thanks.

Anything not in core will not be added later. So no, those won't be in core.

Also, as this question has nothing to do with the issue queue you've posted in, you should open a new thread in the forums, or in the issue queue(s) for the module(s) in question rather than posting in an unrelated issue.

#99 and #108 patches are not working.

Error messages are showing with the patches.

soorepalli : i am able to apply the patch in #108 without getting any error.

16 years later, I think this should be discussed again. There are surely usecases where a "Username" is very untypical and the requirement for a username shouldn't be enforced by a CMS & Framework like Drupal.

One typical example is eCommerce. I know no relevant Shop system that requires a users to enter a username. Same for many many SaaS projects, where the eMail Address is the login.

So while there are workarounds in contrib, I think we should really have a discussion, if the enforcement of a username is still the right way to go for the many use-cases of Drupal?

Back to active as of #129 and the modern SaaS world that left usernames behind in many cases ;)

This is still probably blocked on #1359718: Allow password reset on account with the username matching another email; prevent registrations that match another account and #2014185: Check usernames that are email addresses more rigidly, only allow if matches email - i.e. what happens if one user's email address is user@example.com and another user's username is user@example.com?

I do think we should consider at least a configuration option to allow logging in with e-mail or username in core, it's an extremely common pattern.

That's different from allowing e-mail-only registration though which would be https://www.drupal.org/project/email_registration in core. That gets a lot trickier because we need something to put as display name (content and comment authors), and that defaults to username.

Thanks @catch totally agree - perhaps this topic would be worth a fresh issue too?

One thing regarding your last sentence: I think also that discussion would make a lot of sense for Drupal Core as modern Framework (not specifically as CMS, but as general purpose, Commerce Platform, SaaS foundation etc.): Using no "Username" at all, which means at least hiding the fields entirely for users and site-admins should really be considered not to be a contrib thing.
10Y ago we were in a world, where usernames were common for many things like Forums, Communities etc., but today I think at least 50% of web projects / SaaS with user registrations (excluding things like Communities, where the email address needs to be hidden and an alias used of course), do not use usernames and don't confront users (and developers / site builders!) with it. And I really think Drupal *should* have Username optional in Core long-term.

Or in other words: Think of modern SaaS or Headless frameworks like https://appwrite.io/ or https://directus.io/ I don't think one would hard-code the requirement for a username anymore for user accounts. But Drupal has a different history, where username was best-practice. But I don't think we should stick to that.

One typical example is Drupal Commerce: To register a customer account you have to enter a username (of not using contrib). Which other Commerce system does that? (Hopefully none, for good reasons - it doesn't fit this use-case)

Of course, I know this won't be an easy job, so what I'm talking about here is the strategic perspective.

So should we proceed here or in (separate) issue(s)?

@AnyBody I think it's worth splitting out yeah. There are at least two tracks:

1. Allow user to log in with their e-mail address OR username on the login form - PP on the two issues about e-mail-like usernames. This is not necessarily going to be easy to get done but the scope is quite small and it makes sense in its own right, and for me it would be a normal core feature request.

2. Provide an option to make usernames optional. This has considerably larger scope and it might need to go in the ideas queue of product manager sign-off. While it's a common use-case, projects that don't require usernames will invariably customize the display name, to use first and last names, and core doesn't have anything like that. So we need to ask and answer questions like: - what can be used for display name if username is empty? What happens to the unique, required database column? etc. This would then need its own meta implementation issue for the various bits.

+1 for fresh issues, let's do that! Had the same thought while scrolling through and seems there is consensus :) We can transfer credit to the initial issue for point 1. Don't have time to do this now but I will if no one beats me to it.

Re-rolled patch from #108 to 11.x branch.

It still needs update hook to update new config.

If I read the last few comments correctly this should be postponed on #1359718: Allow password reset on account with the username matching another email; prevent registrations that match another account and #2014185: Check usernames that are email addresses more rigidly, only allow if matches email. And a new issue made for #134 point #2. I updated the issue summary accordingly. Also, hide all the files.

This will also need up to date screenshots, so I tagged for that.