WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 3 years ago

#14834 closed defect (bug) (fixed)

wp_insert_user errors for users without e-mail addresses

Reported by: clifgriffin Owned by:
Milestone: 3.3 Priority: normal
Severity: normal Version: 3.0
Component: Users Keywords: has-patch reporter-feedback
Focuses: Cc:

Description (last modified by dd32)

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. :)


Attachments (1)

clipboard.patch (529 bytes) - added by hakre 5 years ago.
patch against trunk

Download all attachments as: .zip

Change History (13)

@hakre5 years ago

patch against trunk

comment:1 @mdawaffe5 years ago

  • Keywords 2nd-opinion added
  • Milestone changed from Awaiting Review to Future Release

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

comment:2 @CiaranG4 years ago

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.

comment:3 @CiaranG4 years ago

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.

comment:4 @Jeremy Malcolm4 years ago

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.

comment:5 @Jeremy Malcolm4 years ago

  • Cc Jeremy Malcolm added

comment:6 @dd324 years ago

  • Component changed from General to Users
  • Description modified (diff)

comment:7 @CiaranG4 years ago

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

comment:8 @CiaranG4 years ago

  • Keywords has-patch added
  • Severity changed from normal to major

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.

comment:9 @CiaranG3 years ago

  • Severity changed from major to critical

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.

comment:10 @CiaranG3 years ago

  • Keywords 2nd-opinion removed
  • Version changed from 3.0 to 3.4.1

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.

comment:11 @SergeyBiryukov3 years ago

  • Keywords reporter-feedback added
  • Severity changed from critical to normal
  • Version changed from 3.4.1 to 3.0

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' ) );

comment:12 @SergeyBiryukov3 years ago

  • Milestone changed from Future Release to 3.3
  • Resolution set to fixed
  • Status changed from new to closed

Closing as fixed in [18597].

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

Note: See TracTickets for help on using tickets.