Login using email address only (alter display via theming)

this is feature overkill IMO, and it's doubtful i'd add something like this to the module. if you desperately want it, then consider either hacking the module for your personal needs, or writing another contrib that provides this functionality.

Hi,

More and more websites do not use login anymore and just email instead for login.

Look at facebook, google, or myspace for example.

Users just login with their email adress.

The concept of login is too much geek for common users. And users only remember their email adress in general.

Do you think it is possible to remove login from drupal as an option, not only from loggin page but also from the account ?

Thanks

i've marked this issue as won't fix. i will not address it in this module. you either need to file an issue against drupal core, or build a module that will accomplish that goal.

Hey hunmonk,

Could you please reconsider providing an option so the site admins can change the wording "E-mail address or Username"? Like a theme function??? - Thanks!

this sounds like a good overall idea anyways -- it's better to have output text run through a theme function instead of hard-coded, so i'm on board. basically, there are two pieces of hardcoded text related to the login form in LT. they can be found in logintoboggan_form_alter() in the section for the user login forms. one is the username field title, the other is the username field description.

would be great if somebody could roll a patch for both 5.x and 6.x (note they will be a bit different b/c of the theming registry in 6.x)

while this is not a complete solution for this feature request (users would still be able to log in w/ their username if they used it), when LT's email login functionality is enabled, it will allow sites to advertise the login cred they want ("Username or e-mail", "E-mail", or some other phrase) by overriding LT's theme function. In my mind, this handles the most important issue regarding the current limitation -- and doesn't involve getting into the rat's nest of trying fight core for an e-mail only login workflow.

@julma in #2, I say a big Whaa? You said:

More and more websites do not use login anymore and just email instead for login.

Umm, so does Drupal.

You also said:

The concept of login is too much geek for common users. And users only remember their email address in general.

Ok, sure. Drupal + LoginToboggan gives them that ability.

Then you said:

Do you think it is possible to remove login from drupal as an option, not only from loggin page but also from the account?

The short answer is yes, it's possible. The long answer is that no, you won't be able to find anyone willing to do that for you free of charge. Or for less than $70,000, for that matter... ;-)

What we could do is to create an overrideable theme function for that field's title and help text so that site developers could change the text to say "Login using your email address", or "Login using your mother's maiden name", or "We don't want you to login to our site at all, but if you're gonna try, please use your assigned username right here ____".

Hunmonk, if it's ok with you, I'll work up a patch sometime tomorrow that takes care of this little ditty?

@senpai: go for it. i'm happy to commit such a patch if it looks clean and works. :)

Here's a patch that adds theme-ability to all text surrounding the user_login form (the page, but not the block). If this looks good to you, I shall continue this procedure with the user_login_block as well.

The patch creates a section for theme functions at the bottom of the module, and then makes a separate theme function for each of the four textual places on the basic user login form. I purposefully kept it simple so that it's easily over-ridable, allowing changes to one, three, or all four text spots on the page.

These theme functions only operate if the "Allow users to login using their e-mail address" option is enabled.

this needs some massaging...

1. underscores between every word: theme_lt_login_page_user_description, not theme_lt_login_page_user_description. feel free to fix any other old theme functions that are similarly named.
2. the whole $form_id argument and conditional check in the theme functions should go, IMO, unless you can give me a compelling reason to keep them :) i think the code calling the theme function should perform any necessary checks like that.
3. can we change this: $form['name']['#attributes'] = array('tabindex' => '1');, to this: $form['name']['#attributes']['tabindex'] = '1'; in all relevant places? i know that was bad code originally, but it makes no sense to copy/paste poorly done code ;)
4. the description for the username is still hardcoded if 'drupal_authentication_service' is enabled. how about we move that whole if check to theme_lt_loginpage_userdescription?
5. are we sure we want to allow different theming for the page versus the block form? i think there's a slight chance this may be overkill, but i'm willing to listen to other arguments :)

Re: point #1, I so don't understand. It seems like you said the exact same thing.

underscores between every word: theme_lt_login_page_user_description, not theme_lt_login_page_user_description

What'd I miss here?

Re: point #2, I had originally started to write a 'smart' theme function that would differentiate the calling form as either a user_login page view or a user_login_block. I abandoned the theory only to get his first draft of code out the door. If it's a good idea, I'll continue down that road?

Re: point #3, Sure we can change that. Stylistically, it seems to say the same thing, but as long as you think Drupal can predict that #attributes is indeed an array, we'll loose the old way and make it more readable. ;-) No problem.

Re: point #4, Good idea! I sorta noticed that, but didn't want to go too far outside the scope of this patch. I have a habit of 'just trying to change this one other thing...'.

Re: point #5, I'm envisioning a use case for a user_login_block to be descriptive-free. It would seem to me that if I was putting a login block on a site, I'd want two fields and nothing more. If I couldn't override the theme function for that login block without also changing the regular login page's description, I'd be pretty pissed for at least 12 minutes or so. I'm just sayin! What do you think? Can I keep 'em separated?

#1: whoops. should be theme_lt_login_page_user_description, not theme_lt_loginpage_userdescription

#2: ah, i see your point. yes, continue w/ that, it will give themers more flexibility.

#3: no, the problem there is that if there's anything else in the #attributes array, it will get clobbered the way it's currently written. we know #attributes is an array, so go ahead and make that adjustment.

#5: i think if you do #2, you give themers the ability to do it, so i don't see the need for separate theming functions.

Done, done, and done.

#attributes array is fixored.

I re-combined the two cases I had originally separated out. They're now
case 'user_login':
case 'user_login_block':
back into a single chunk again, since there's now a smart theming function that handles all the nitty gritties.

1. the user_login_block case of theme_lt_password_title() looks wrong.
2. Drupal coding standard is e-mail, not email, so those need to be changed.

this is looking pretty good otherwise. once you fix those two things, i'll run it through some tests.

Wow, how'd that one slip through the cracks! Fixed, and fixed.

i've made some adjustments/cleanups:

1. moved from conditionals to state machines in the theme functions.
2. added proper doxygen to the theme functions.
3. removed all logic from theme_lt_password_title() -- it was unnecessary.

ran some quick tests, and everything seems ok.

@Senpai: can you have one more quick look at my work before i commit?

subscribing

Patch applied and tested for user/login and user_login_block with e-mail_address feature turned on and off.

This looks great! Let's send it on down the highway. Yeah, umm, I debated switching my theme function conditionals to states once that third if else() was needed to handle the drupal.module's affiliate login condition, but then I got lazy. Thanks for the final cleanup on this one.

committed to 5.x

@Senpai: think you can port the work here to 6.x? i'm getting some failed hunks.

Very nice. I noted that LT uses "Username OR e-mail address:" on the login page, while core uses "Username or e-mail address:" on the "Request new password" page. (All caps vs. lowercase.) For consistency, may I suggest using "or"?

committed to 6.x. i also got rid of all the all caps stuff in the login forms -- what's the point in shouting? ;)

Cool. You made it work for 6.x!

I doubt, however, that removing the 'OR' from the username description is a good idea, mostly because it creates a visual cue that this login form is somehow different from every other "username goes here" input field. I'll leave it at that, and I'm not re-opening the case just for this.

Hi,

I've tried to apply this patch to the latest Drupal 5 (5.x.12) version, but not all changes went through and the logintoboggan module was rendered useless...
Could someone please offer some help on how to apply these changes to 5.x.12 so that my users don't need usernames, just their e-mail addresses?

thanks
peter

well in my project it should be an input type email for validate email adress before send the form and i use 5.7
so how can i do it?

Adding my 2 cents here

There is another project called Email Registration, which allows the creation of the username based on the email address.
http://drupal.org/project/email_registration

If its email only registration feature could be incorporated into logintoboggan, the latter would become THE tool for login.

Just a tought

@FCX: has anybody tried to get logintoboggan and email_registration to work together? just curious...

it is not still? i need to ligin by email only!
thanks

Don't get me wrong, login by email does work.

I just tried both the email_registration module with the logintoboggan module and the registration still required a username to be entered, preventing anyone from hiding the field from the registration form (which is what a lot of people seem to request).

I am sure this is something really simple to do, because the functions are already out there and working very well.

Always down to the same thing : the need for someone to spend some time on it.

Now, I am pretty new to Drupal, and intend to write/improve a (hopefully some) module(s) some day. But, as of now, I prefer to watch and work my way along the learning curve of Drupal.

This appears what feature people are looking for in this issue:

http://drupal.org/project/email_registration

I can't see using email_registration module, can see it now when a user enters in a disposal fake email address wgzkb@spamrus.com, their user name would then be wgzkb, no thanks.

There is no need to get all worked up on this. The reason why users request an email address over usernames is because for commerce sites its more applicable rather than using an alias. However if you don't want to hard code it into logintoboggan its clearly understandable, since it will be re-inventing the wheel. My suggestion is if you can make logintoboggan work with ITweak login then it will be better for us all. Since ITweak login allows you to rename the field labels found on the login block allowing you customization without any hardcoding. Unfortunately logintoboggan disables renaming the username and password fields. Atleast you can put some thoughts into this.

@espirates

The username in email_registration is only generated to please drupal's requirement of one. I use this module in conjunction with RealName so usernames don't display at all on my site.

Unfortunately logintoboggan disables renaming the username and password fields

it does? all i'm doing is form_alter'ing core's login form. any module weighted to run it's hooks after LT can do whatever it wants to the login form.