Skip to:
Content

BuddyPress.org

Opened 8 years ago

Closed 8 years ago

#3949 closed defect (bug) (fixed)

{wpprefix}_bp_xprofile_data

Reported by: Ninos Ego Owned by:
Milestone: 1.5.5 Priority: normal
Severity: normal Version: 1.5.4
Component: Extended Profile Keywords:
Cc:

Description

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

Change History (6)

#1 @DJPaul
8 years ago

  • Severity changed from blocker to normal

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

Last edited 8 years ago by DJPaul (previous) (diff)

#2 @DJPaul
8 years ago

  • Component changed from Core to XProfile
  • Keywords reporter-feedback added

#3 @johnjamesjacoby
8 years ago

  • Version set to 1.5.4

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.

#4 @boonebgorges
8 years ago

(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.

#5 @boonebgorges
8 years ago

(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.

#6 @boonebgorges
8 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to 1.5.5
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.