Email only registration
xweb - April 2, 2007 - 03:31
In my module, using hook_user to remove Username from required fields i cannot set $edit['name'] to be the same as $edit['mail'].
I want workflow to be - user register (email only), Confirm, edit profile to change username (Display Name)
With this code the process borks in user_validate_name at 'You must enter a username.' seems the $edit variable did not accept new value.
<?php
/**
* Implementation of hook_user().
*/
function mymodule_user($op, &$edit, &$account, $category = NULL) {
if($op == 'validate') {
$edit['name'] = $edit['mail'];
}
return;
}
?>
Try hook_form_alter
Try using hook_form_alter instead and alter the basic form information instead. Drupal forms are set up so you can't edit them outside of the form function except using hook_form_alter for security reasons.
Dave
I am using hook_form_alter
I am using hook_form_alter also to hide the 'name' text input. What I want to do is take the email address, obscure it and then make that the username, all without the new user knowing. To the user it looks like sigining up with just an email address.
The problem i'm having is that i cant change the values of &$edit from within hook_user.
xweb
form_submit_validate?
I know it's possible to either over-ride the current form's validation function or submit function. It may also be possible to add an additional validation function. In validation and submit functions its possible to change the form values.
Worst case scenario, you track down the current user form validation function, copy and paste it into your module, and modify it to suit your needs, and then override the validation of the user registration form.
Does this make sense?
That's something I was not aware of.
I was not aware that a Drupal function could be overridden. I did a search for this once and it yielded not a single suitable result.
How would one override a function in this manner via a module - ie without touching core, a simple snippet or link to an answer would be immensely appreciate.
Thanks for your advise.
Chris.
xweb
Not actually over-riding the function
Hrmm, I mispoke. What I meant to say is that a form has a validation function, and it is possible to change the validation function that is used. The validation function is basically one of the form elements.
Here's an example of what I mean.
Suppose the user registration form has a id of 'user_registration_form'. You use hook_form_alter, and use some logic to make sure the current $form_id == 'user_registration_form'. Then you find the specific form element you want to change, which is presumably, $form['name']. Then you do something like the following below.
<?php$form['name']['#validate'] = array('mymodule_custom_name_validation' => array($form['email'])),
);
?>
So here I am redirecting whatever validation the user.module usually uses to the function 'mymodule_custom_name_validation', and to this function I'm passing an array of values. If you look at the filter.module, it apparently does something like this. Check out the function 'filter_form_validate' to find out what values are passed to the validation function normally, you may not need to specifically send $form['email'] to it.
Validation functions are allowed to change the values of the forms they work with, so you shouldn't have any difficulty there. In your validation function you will, of course, want to confirm that the name is unique, etc... (check with the regular user name validation to see what things they check, and mimic that function).
Does this make sense?
It's all about the trickery
You can accomplish this by settings a fake (random, in my case) username within a hidden form field and then rewrite the form values during validation.
<?php
/**
* Implementation of hook_form_alter().
**/
function example_form_alter($form_id, &$form) {
switch ($form_id) {
case 'user_register':
unset($form['name']);
$form['name'] = array(
'#type' => 'hidden',
'#value' => user_password(),
);
break;
}
}
/**
* Implementation of hook_user().
**/
function example_user($op, &$edit, &$account, $category = NULL) {
switch ($op) {
case 'validate':
global $form_values;
$form_values['name'] = $form_values['mail'];
break;
}
}
?>
This tricks the form validation into thinking the username is set and then lets you rewrite it once you know you have a validate email address.
Yes, this is similar to what
Yes, this is similar to what I ended up with, not as elegant as your's but may be useful to someone.
<?php
function mymodule_form_alter($form_id, &$form) {
if ($form_id == 'user_register') {
$form['account']['name']['#type'] = 'hidden';
$form['account']['name']['#value'] = md5(rand(0,999));
}
}
function mymodule_user($op, &$edit, &$account, $category = NULL) {
switch($op) {
case 'insert':
$newname = preg_replace('/@.*$/', '', $edit['mail']);
// to fix - dupe random names can be created although not likely,
// still there's no error checking, sequential would be nicer -- later
$newname .= rand(0,99);
db_query("UPDATE {users} SET name = '%s' WHERE uid = '%s'", $newname, $account->uid);
break;
}
}
?>
Which creates a username based on their email address, as I found that having a username is VERY important. On the site i developed that required email rego and logins I relabeled username to 'Display name' All works well, I did some work on allowing email as a login also. LoginToboggan http://drupal.org/project/logintoboggan provides these features I later found although has many more features than I required.
Did these modules ever get
Did these modules ever get released publically? I have a need for something similar and didnt know if you wanted to share :)
--
blah
Those are the modules
I think those are the entire modules...
Dave
My site: http://www.unitorganizer.com/myblog
I've currently got many
UPDATE: see project http://drupal.org/project/email_registration
I've currently got many other commitments although when time permits I may create this as a usable module.
Please +1 this thread if the module would be useful to you.
http://www.xweb.com.au
+1
Very much in time!
I've planned to hide (generated) usernames and show it from (user-defined) profile fields (realnames: prefix, first, second, last) passed thru (user-choosed) formatters.
+1 for this module, it might
+1 for this module, it might come in handy for future projects.
Youfolder.com
Share what's in your folder for the Hispanic community in Canada.
download module at
http://www.hyrme.com/files/loginbyemail.zip
paid for by: seth97 at http://drupal.org/user/24303
email_registration AND loginbyemail?
@ Chris Herberte & panis,
Is there any reson either of you can see why I shouldn't use BOTH of your modules? email_registration AND loginbyemail?
The reason is with email_registration only, the login block form replaces "username" with "email", and allows the users to login with either email or username (nice for those already registered).
However, the registration page still requires a username. Which I don't want if I'm having them log in using only their email & pass.
With loginbyemail only, this solves the registration page issue (users only have to register with their email).
But, my login block still asks for a username.
SO I enabled them both. And so far, all seems to be ok.
MY BIG QUESTION IS do you think this will cause conflicts between the two modules? I did see that when a user registered, and then I changed that user's password as admin, it modified the user's alias from a random name to a name based on their email prefix. But I don't know if this is a problem, or just a benign redundancy.
Please let me know if you can? Thanks in advance...
SCott
registered users don't receive email
Not sure if this is an effect of installing both mods, but when I register as a user, I don't receive the promised email.
I tried to uninstall the most recent module (loginbyemail) so I could try to reproduce the problem without it, but then I can't register at all because the username field is still hidden (as with the module) -- but it is also required (as before I installed the module) = so now I have no way to register unless enable loginbyemail again! (So did it make a database change? )
Now I am somewhat captive until this is solved -- that's what I get! :( Please help!
Thanks in advance
Scott
if you uninstall the module
if you uninstall the module - it cant turn off your username - it uses hook-form_alter to do it and if it is disabled this function does not get called.
there is no database changes the module makes.
the email_registration also disables displaying the username field - that is probably what you are seeing. see line #70 in the module file. Temporarily to restore sanity you can comment out that line in the email_registration.module file and keep working..
they are both simple modules
they are both simple modules - I do not mind merging them together - but looking at the email_registration module I think you can get by with the only that module because that too allows you to only register with your email addr - if a minor bug or detail in it is fixed.
During registration the name field may not get hidden when profile information is present because it does not look at the $form['account'] fields. the registration form depending on where you are coming from can be either stored in the $form['name'] fields or in a sub-element of $form at $form['account']. The email_registration only uses the flat form structure i.e. $form['name'] variables..
It looks as though there are
It looks as though there are many Drupalers that require the functionality of the discussed module/s
I will be supporting the development as much as possible over the holidays of email_registration, adding any feasible feature requests, starting with administration options. Scott, this would include the issues you describe which I will attend to ASAP.
Please submit support and feature requests, bugs and patches to http://drupal.org/project/issues/email_registration
thanks
ok, thanks Chris & panis,
Looks like I should work with email_registration -- I'll move attention over to the issues queue for that mod.
happy holidays,
Scott
Scott Rigby
http://basekamp.com
http://PlausibleArtworlds.org
+1
Needed. Don't fancy changing usernames to emails post-launch.
So, I would have needed to implement this myself some day before launching next project. Before letting any users in.
Will continue based on your code.
Thanks!
if your users already have
if your users already have user accounts with normal names - this will not affect it. Only new users should be forced to use the email addr as login.
+1
Very useful. Needs some bug fixes.
It would be perfect in combination with a module for hiding usernames and showing CCK fields instead.
An important difference to
An important difference to note between xweb's original
hook_usersnippet and Chris' snippet is the$operation in which the changes to the$editfields are performed...I believe that if you need to alter the contents of
$edit, you should do so in$op == 'submit'or possibly in$op == 'insert', and NOT in$op == 'validate', which would have no lasting effect across $op's.All the possible
$op's are listed here:http://api.drupal.org/api/function/hook_user/5
And although it may not be strikingly clear from those API docs when you should be altering the $edit fields (if you need to do so), I ran into a similar case but was using nodeprofile module to modify user registrations, and subsequently doing a very similar operation but using
hook_nodeapi(since nodeprofile makes user profiles into nodes)... FOR WHICH the API documentation DOES clearly state:That gem was a stumplifter for me... hope it helps someone else.