{wpprefix}_bp_xprofile_data

[Ninos Ego]

In the db-table {wpprefix}_bp_xprofile_data buddypress is creating a row with userid 0 and 1 of random users. I think on registrating of a new user.

I've got the newest trunk version of buddypress...

Fixing temporary this problem, I must delete these rows in the db..

Because of that there's a bug on the registration page, too.
The content of the custom input fields are the value of these rows..

Also on {wpprefix}_usermeta it creates these fields.. So my name (admin name) is changed to another user..

[DJPaul]

I cannot recreate. I am testing creating a new user, with a custom profile field in the default group.

[johnjamesjacoby]

It looks like there might be a language barrier here, but it will help us immensely to have clear and accurate steps to reproduce this issue.

[boonebgorges]

(In [5840]) Some hardening of the member registration process:

• Ensures that pre_user_login filters are applied before attempting to create a user with wp_insert_user(), so that BP's username validation is the same as WP's, and username_exists() checks are reliable.
• Check to see whether the return value of wp_insert_user() is a WP_Error object before continuing with the registration process.
• Improves error handling during user creation, by correctly parsing WP_Error objects returned from wp_insert_user().

See #3949.

[boonebgorges]

(In [5841]) Some hardening of the member registration process:

• Ensures that pre_user_login filters are applied before attempting to create a user with wp_insert_user(), so that BP's username validation is the same as WP's, and username_exists() checks are reliable.
• Check to see whether the return value of wp_insert_user() is a WP_Error object before continuing with the registration process.
• Improves error handling during user creation, by correctly parsing WP_Error objects returned from wp_insert_user().

See #3949.

[boonebgorges]

I believe I have fixed the problem.

From what I could trace, it was due to some problems with the way that BP validates usernames. When we validate a requested username, we do not run the pre_user_login filters that are run in wp_insert_user(), which means that the username we're validating (such as one that includes spaces) is not the same as the one that is used by wp_insert_user() to create the actual account (which would have spaces stripped by BP's bp_core_strip_username_spaces()). As a result, certain username conflicts may not be detected by BP's registration validation, resulting in WP_Errors being returned from wp_insert_user(). Compounding matters, we were not checking to see whether wp_insert_user() was returning an error object (only checking to see that it was returning *something*). As a result, BP was attempting to updated xprofile data with a user_id that was not a real ID, but was instead a WP_Error - which, when cast to an integer, ended up as a 0 or a 1.

I believe that these errors have been fixed by r5841 and r5840. If you find that the problem arises again, please reopen the ticket with steps to reproduce.