wp_insert_user errors for users without e-mail addresses

[clifgriffin]

Greetings,
In versions previous to WP3, it was possible to pass wp_insert_user an array with or without an e-mail address and the user was created without issue.

In WP3, a check was added to determine whether or not the user already exists by their e-mail address.

if ( !$update && ! defined( 'WP_IMPORTING' ) && email_exists($user_email) )
          return new WP_Error('existing_user_email', __('This email address is already registered.') );

The problem with this check is that it matches the admin account if you pass it a null or blank e-mail address. The admin account, being created by the installation script, does not start with an e-mail address.

This has caused one of my plugins (Simple LDAP Login) to fail. To fix this, I had to do this:

if ( !function_exists('get_user_by_email') ) :
/**
 * Retrieve user info by email.
 *
 * @since 2.5
 *
 * @param string $email User's email address
 * @return bool|object False on failure, User DB row object
 */
function get_user_by_email($email) {
	if(strlen($email) == 0 || empty($email) || $email == "" || strpos($email, "@") == false)
	{
		return false;
	}
	else
	{
		return get_user_by('email', $email);
	}
}
endif;

Please consider changing this behavior in future versions. I hate having to modify core functions to keep a plugin working. :)

[hakre]

patch against trunk

[mdawaffe]

Patch makes sense to me. I'm not sure how your admin account doesn't have an email address, though.

[CiaranG]

This breaks the OpenID plugin too. As soon as more than one email-less account registers, it starts throwing out "email address already registered" errors.

[CiaranG]

To fix the problem to allow the OpenID plugin to work again, I simply changed a line in wp_insert_user, from:

if ( !$update && ! defined( 'WP_IMPORTING' ) && email_exists($user_email) )

to:

if ( strlen($user_email) > 0 && !$update && ! defined( 'WP_IMPORTING' ) && email_exists($user_email) )

In other words, it's permissible to have more than one user with a blank email address field.

[Jeremy Malcolm]

The patches to pluggable.php and registration.php stop the errors, but they don't fix the problem. I still can't login with a new OpenID. When I try, an OpenID user is created with no email address, but I can't log in with it. The login screen just reloads itself. If I try logging in again with the same OpenID, it creates a second OpenID user with a numeral appended to its username.

[CiaranG]

This is still a problem. I'm having to re-modify WordPress core code every time an installation is upgraded. :(

[CiaranG]

Still broken in the 3.3 release.

I can't see what is wrong with the simple fix in comment #3, which changes it from being completely broken for various very useful and commonly used plugins, to working properly with no side effects.

[CiaranG]

Still broken in 3.3.2. It's an extremely simple fix, as I outlined in comment 2 above, and I can't see how it's controversial in any way.

[CiaranG]

Still broken in 3.4.1.

To fix the problem to allow the OpenID plugin to work again, I simply changed a line in wp_insert_user, from:

if ( !$update && ! defined( 'WP_IMPORTING' ) && email_exists($user_email) )

to:

if ( strlen($user_email) > 0 && !$update && ! defined( 'WP_IMPORTING' ) && email_exists($user_email) )

In other words, it's permissible to have more than one user with a blank email address field.

[SergeyBiryukov]

Version number indicates when the bug was initially introduced/reported.

Replying to CiaranG:

Still broken in the 3.3 release.

Have you verified that?

Since [18597], email_exists() returns false for empty strings, due to the check in get_data_by():
​http://core.trac.wordpress.org/browser/tags/3.4.1/wp-includes/capabilities.php#L500

I could not reproduce the original bug. This code successfully creates two users with blank email addresses in both 3.3 and 3.4:

wp_insert_user( array( 'user_login' => 'user1', 'user_pass' => '123' ) );
wp_insert_user( array( 'user_login' => 'user2', 'user_pass' => '456' ) );

[SergeyBiryukov]

Closing as fixed in [18597].

Feel free to reopen with more information if there's still a problem.