The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Many sites these days just have an e-mail and no (visible) username. It would be great if commerce would support this with a setting
Proposed resolution
Login with e-mail and hiding the name for registration is pretty easy, the main question is what to use as username. In our case, we use the e-mail 1:1 as username, that might be OK as a default, otherwise we could have a token/event to customize it.
Comments
Comment #2
berdirHere's a first step that works for me (tm):
https://github.com/drupalcommerce/commerce/pull/677
Questions/Todo's:
* Not sure about name, title and description.
* No special login handling yet.. in my case I've overriden the user authenticate service, so this already works for my site. We could also explicitly load the user by e-mail. But it also works like this with users created with username = e-mail.
* Login and registration could be separate settings, login for example could be a tri-state: username, e-mail, both.
* No configuration yet for username handling
* Also no tests yet.
Setting to needs review to get some feedback.
Comment #3
tormi+1 for this FR.
Would be ideal, if we could use user's first + last name which are currently part of a customer profile via address module (address:given_name and address:family_name).
By using e-mail 1:1 as username we are risking of exposing the e-mail to the public.
Comment #4
berdirNames are not unique, so you'd need some deduplication logic to end up with John Smith2 which is a bit weird. But something like this would be possible with token support.
Comment #5
berdirAlso, the name is not available until the user fills out the address, so actually, that's not really an option. In our project, we have separate fields for the name and use username alter hook to change the display name.
Comment #6
mglamanSo people are using custom setups (I know I do!) or https://www.drupal.org/project/email_registration. Perhaps we need to make sure we work well with email_registration?
Comment #7
berdirI've been discussing and thinking about this a bit.
As I mentioned, we have custom implementation of this (e-mail only login and registration), and there is more than one module providing such features (there is also login toboggan for example). email_registration also seems to consist only of a bunch of form alters, using various tricks to make the login work.
In my custom implementation, I'm replacing the user auth service, so any way of authenticating works, including basic_auth and so on.
If that module were more of an API, then maybe integration with it would make sense, but right now, there isn't really much to integrate with.
I see that it might be quite hard to find a solution that works out of the box for everyone. In the meantime, I actually got some additional requirements about additional fields that need to be present on the registration form.
What about, as a first step, to refactor both the submit and possibly also building the form into multiple methods, to make it easy to subclass and customize? I can open a separate issue for that.
Comment #8
jonathanshawemail_registration now offers a commerce checkout pane for this purpose.
Comment #9
smccabe commentedTested and confirmed email_registration covers the issue as in the issue summary. Berdir had some additional API related ideas, but those should probably go into separate issues, as he mentioned.
Going to mark as fixed based on that.