WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#32222 closed defect (bug) (duplicate)

Silent error on attempt of user creation

Reported by: psycleuk Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Database Keywords:
Focuses: Cc:
PR Number:

Description

The change from [32307] causes any database inserts or updates to silently fail if the content length of a column is longer than the database allows.

However in testing we found that creating a user with a long user_login (which is allowed to be up to 60 chars) causes a user_nicename to be automatically generated that is longer than the 50 chars allowed. The insert simply returns false, and the user_id returned from wp_insert_user is simply 0.

I've not looked but I can see other situations where this silent error could occur. Would it not be better to return a WP_Error of some kind?

Change History (5)

#1 @psycleuk
5 years ago

Ah wait, this may be a extension/duplication of ticket #32167

#2 @ruud@…
4 years ago

  • Keywords needs-patch added

Ran into the exact same problem in WP 4.2.2

Allowing user_login to be 60 characters long and then using is to populate another user property (user_nicename) which can be only 50 characters long is kind of a problem.

Should we go for: throwing an error? probably not since allowing 60 characters for the user_login is perfectly legit.

Truncating the string used for the user_nicename field is another option, however this could lead to 'strange' user_nicename values. To avoid strange truncations, this could also be made to keep the user_nicename field empty when over 50 chars.

Adding a user_nicename entry field in the sign-up proces is another solution. This however clutters the sign-up proces.

Having said all this, my choice would be to leave the user_nicename field empty when user_login is over 50 characters.

Any thoughts?

#3 @ruud@…
4 years ago

  • Keywords dev-feedback added

Did some further digging into the user_nicename usage.. in the wp_insert_user() function this gets more complicated because the code is also actively checking for the uniqueness of the user_nicename string.. and suffixing it when not.
In the case the user_nicename would be empty this code would then result in user_nicename values of '-2', '-3' and so forth..
This doesn't scale very well.
Another aspect: a user_nicename length could be exactly 50 (and in use..), resulting in a user_nicename with suffix, and subsequently a failed database insert action because the new string is larger then the column allows.

#4 @ruud@…
4 years ago

current workaround in project:

add_filter( 'pre_user_nicename', 'pre_user_nicename_filter', 10, 1 );
function pre_user_nicename_filter( $user_nicename ) {

	//truncate $user_nicename to 47 chars length to allow for double-digit unique value suffixing and still fit into 50 chars database column
	$user_nicename = substr( $user_nicename, 0, 47 );
	
	return $user_nicename;
}

#5 @pento
4 years ago

  • Keywords needs-patch dev-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed
  • Version 4.2.1 deleted

Duplicate of #33793.

Fixed by [34218].

Note: See TracTickets for help on using tickets.