Make email not required for a Drupal site account

I have created a Drupal 6 module which allow sign-up without a valid email.

As drupal core requires an email, therefore 'null-(rondaom-string)@localhost.com' is automatically generated without displaying and stored into mail field.

I got a solution without hacking the core. May be it can be turned into a module if it proves to be useful and there is a demand for it.

This solution is non-intrusive, if your guard condition is not true, it won't affect anything.

Here is how:

1. in your hook_form_alter()
   1.1 set email required to false
   1.2 points validation to your function
2. in your validation function
   2.1 if email field is empty, then stuff a garbage email value (should be as unique and non-existent as you can imagine)
   2.2 invoke the original validation
   2.3. empty out email afterward as needed

Sample code is for 6.x.

function mymodule_form_alter(&$form, $form_state, $form_id)  {
...
    if ($form_id='user_register' && whatever your guard condition is true) {
       	$form['mail']['#required'] = false;
       	$form['#validate'][0] = 'my_user_register_validate'; // to be accurate you should check if $form['#validate'][0] is 'user_register_validate' before reset it
   }
...
}

function my_user_register_validate($form, &$form_state) {
  
  if ($form_state['values']['mail'] == null) // if no email value, then stuff a temp one to fool the validation
     $form_state['values']['mail'] = 'nobody@nowhere.com'; // a unique non-existent email
     
  user_register_validate($form, $form_state); // call original system validation
   
  if ($form_state['values']['mail'] == 'nobody@nowhere.com')
     $form_state['values']['mail'] = ''; // stuff empty back again
}

However, if you allow empty emails (such as for kids in a family), then some modules may not work as designed if these modules assume each account has a valid email. Well, like they say, you can't have it both ways ;-)

The above logic takes care of registration email, but it still requires email if you edit your account. So I just whipped up a small module that takes care of both.

The module is very simple. Just enable/disable the module as you need. If anyone tries it, please let me know your feedback. I may submit it as a module. The source code is for 6.x.

Thanks.

Hi ubuntu,

This works perfectly, thank you for the module, I tried it on 6.6 and it works as advertised... I think this would definitely be helpful, so if you could publish this it would be a help to a great many folk.

If I may offer a quick suggestion - if there any way to add an additional "Security" field during registration with this module, so that users have at least 1 option to be able to recover their password?

Thanks again for this!

Actually, just to give you a heads up. I just started to heavily use this module and came across a slight error... seems as though it throws a "malformed header from script ... in file index.php" Apache 500 error right after the user submits for registration and the account ID/password are written to the DB. I'm using v6.6 at this moment.

I think I found what's happening - Drupal seems to be doing a condition check on the email address field in the users table, and because nothing is there it's bombing out.

I'm going to see if I can alter the email notifications to either manually put in a fake email address or bypass the condition check altogether... just thought I'd update what the actual issue is. It's too bad this isn't a complete module, sounds like people really are clammering for something like what this does.

This is good information. I figure anywhere that requires email will cause problem. This is one of those places. My hunch is there may be other places.

I didn't encounter this because I hacked the user module that bypassed email notification with my condition.

If you don't mind me asking, how did you do the override for the user registration? That's really the only piece that I have on my site that's going to be using email (other than the global contact form, which is a seperate module and has hardcoded email addresses). Everything else is confined to the site itself...

You ever think of publishing this as a valid module and letting the community help build it out?

No problem. Here is my hack, for drupal 6, user.module, around line #2349

    else if (!variable_get('user_email_verification', TRUE) && $account->status && !$admin) {
    
          //  hack 
          $url = drupal_get_path_alias($_GET['q']);
          if (strcmp($url,'mygroup/add') == 0)  { // add a new member
            drupal_set_message(t('New accout is created.'));
            return '';      	
          } // skip the rest, so the original user is logged in...    	

This may point you to the idea. Your logic should be different based on your application.

I haven't spent enough time to validate that the module covers all corners. I may formally submit it later when I get some more feedback so I can turn it into a robust module. In fact, I believe the same simple principle can be used to build the "shared emails" as well.

Thanks again ubuntu, that lead me into exactly the area I was looking for. I just commented out _user_mail_notify('register_no_approval_required', $account); at line 2349 and this bypasses the email notice being sent out to new users who don't require approval. Error is gone, things are good again. :)

Thanks for your help - let me know if you need any testers for this module if you decide to take it any further. I'd be glad to offer my services.

I've backported this module to D5. There are some specific additions to the module for the project I'm working on, but I could strip those out if anyone is interested in it.

I actually had to circle back on this as I realized that we needed a random email generator since Drupal is also checking for unique emails... so to that end I added a random number generator function that appends the email address... this should do the trick for most sites until something more official is implemented into core. :)

Moved from feature request to bug report because several modules create user accounts without providing email addresses. Later, administrators cannot edit these accounts (i.e. to add a role) because the user edit form insists on having an email address.

Attached patch is for D6 because that's what I happen to be working on. Hoping someone can port the code to D7, if it does not apply...

The attached patch does not alter default drupal behavior in any way at all. However with the attached patch, a third-party module can simply remove the #required from the mail field (via hook_form_alter) and everything will work as expected. I understand the workarounds above accomplish the same result, but really it should not require so much effort. let's fix core!

rerolled for 7. code and functionality look good. i would rtbc this but the bot must approve first.

That would also have to be handled by the module that removes the #required. Core is just trying to get out of the way, not actually fully handle the no email case.

I can't tell what test failed. :(

What Moshe said. If the contact module fails when a user has no mail address, thats a separate bug in the contact module.

I too cannot tell what test failed. let's try the same patch again.

I don't intend to be cut-throat. It's just that if we tried to address every module which might have a problem, we'd never get this change checked in. I remember this coming up in Drupal 5 and probably previous versions. Its not easy to get any change into core, but the smaller the patch the more likely to be checked in, I think.

Its true that contact is in core, and it would be great if all of core did not assume every user has an email. But we have to start somewhere, and I believe this patch is a logical start. And I can guarantee this patch will not break the contact module, because this patch changes nothing. It's this patch in conjunction with a custom module which removes the #required, only that combo changes behavior. And if my site with my custom module cannot use the contact module, then I'll either live with that or submit a separate patch to contact.

...or you can augment the above patch with changes to contact and we'll review them. But keep in mind there are third party modules already creating users without email addresses. If contact fails in that case, then it's already failing on those sites. All I'm personally trying to accomplish here is that as a user administrator I can use the account edit form. That's why I see contact or any other module as separate.

P.S. I still cant determine why the patch failed.

Looks like there is a test specifically to test the email validation when email is blank. I think we need to patch the test, too.

@ comment #4
The patch uses $form['mail']['#required'] = false; in the form "user_register". This does not always work since there are situations in which
$form['account']['mail']['#required'] = false; must be used. An example for such a situation is when you have multiple sections at admin/user/user/create. For example once section for your "Account information" and another one for "Language settings". So I guess that the patch does not work for a lot of users.

Easy to fix in Drupal 6.16!

Simply delete the following line from user.module:

_user_mail_notify('register_no_approval_required', $account); (line 2374)

... and of course configure your system not to require user email confirmation.

.

@Asif99

Have you shared this module? Where is it? Thanks.

user's mail is tightly involved in registration and notification so all previous patches are wrong.

suppose this mostly related to pluggable auth and mail handlers in upcoming initiatives

I believe a good patch for drupal 8 would:

- have a switch for generally disabling and hiding email address in the user account.

This would avoid every external authentication and profile module from doing the same hiding and form altering on the user edit form. A hook_user_email_instantiated() could be used to communicate if an individual account's email field is in use or not. This would be be ideal for mixed authentication scenarios.

As the previous discussion clarified, there is just no way to predict all the uses the email field has and alter all the forms involved.

FYI there's a really similar issue, originally posted against Drupal 5.x, now against 7.x. #189544: Allow administrator to edit account without email address (regression: accounts can be created without email addresses also)

Has there been any stable solution recently for D7?

Apollo610 had a great start with his mini module. Unfortunately, there were some items that needed to be corrected.

First, rather than replace the original validation in the form_alter function, doing this makes more sense...
array_unshift($form['#validate'], 'my_user_email_validate');

The custom email validation has to come first in the validation lineup in order to work, otherwise the standard validation is called first and the validation will always fail. Also, then there is no need to explicitly call the native validation function as its still in the validation array

Rather than a random number generator for the emails, personally I prefer using a timestamp from time().

Finally, it's not enough to change the value of the email in $form_state['values']['mail']. I was able to make this work by first changing the value of
$form['account']['mail']['#value'].

Otherwise, that little module was a big help in getting this working in my project. Thank you Apollo610!!

Hello Guys,
This module is very simple.

It makes email field nonmandatory on registration and profile updation.

Check out. If any correction, let me know.

17: mail.patch queued for re-testing.

From comment 21, for code "elseif (db_result(db_query("SELECT COUNT(*) FROM {users} WHERE uid != %d AND LOWER(mail) = LOWER('%s')", $uid, $edit['mail'])) > 0) {", it is not available in drupal7 and drupal8. There is a different style of writing/executing code in drupal7. Made the changes for drupal6.

Do not change the branch

with no change in the branch.

@jyotisankar first the issue should be fixed in 8.x

Also the issue looks a duplicate of related

looks this will go in 8.1

I started some work in this direction. Please check it out and suggest improvements.
Module: Simplified Registration (sandbox)

It's a valid feature, but what's the argument for this being core not contrib? If there isn't one, we can "won't fix" this issue.

DRUPAL 8 : If you want to make email field as optional for anonymous user, you just need to do add your custom validation for user registeration form :

For Ref. :

/**
* Implements hook_form_alter().
*/
function YOUR_MODULE_form_alter(&$form, FormStateInterface $form_state, $form_id) {
if($form_id == 'user_register_form'){
$form['#validate']=[];
$form['#validate'][] = 'YOUR_MODULE_custom_user_validation';
}
}

/**
* Implements YOUR_MODULE_custom_user_validation().
*/
function YOUR_MODULE_custom_user_validation(&$form, FormStateInterface $form_state) {
$form_state->setTemporaryValue('entity_validated', TRUE);
}

Using above code in your own module you will be able to register an account without using email id.

I suggest we don't fix this in core: it can be solved well in contrib and the lack of recent engagement suggests it's a less common need.

It is not solved for core at all, contrib is here to get common ground and fix it in core

All patches are for 7.x and here 27 people following

Search engine carried me here.
With the hopefully upcoming rise of WebAuthn this need is likely to increase.
SO +1 for keeping this open.

During a BugSmash group triage meeting with darvanen, lendude and myself we triaged #2600158: User email requirement is inconsistent and found it to be a duplicate of this issue. The lendude pointed out that the likely 'root fix' is #2227381: Apply formatters and widgets to User base fields 'name' and 'email'. We all agreed that this issue should be postponed on #2227381: Apply formatters and widgets to User base fields 'name' and 'email'.

Also here via search, also building a site involving user accounts for people of all ages, including very young, for whom an email address is inappropriate. It'd be great if this wasn't necessarily a required property/base field.

I understand the desire to "solve" this via #2227381: Apply formatters and widgets to User base fields 'name' and 'email', however, the required bit is not something that can be controlled via widget nor formatter. That's a property of the field/basefield/property itself. Even if we were using regular field widgets for these things, how would we be able to control if this is required or not?

Can't this proceed as a parallel effort? Don't we need something other than widgets or formatters to both let site builders control if this property is required, and teach the rest of core / contrib that email isn't necessarily always available?