[buddypress-trac] [BuddyPress] #3949: {wpprefix}_bp_xprofile_data

[buddypress-trac at lists.automattic.com]

#3949: {wpprefix}_bp_xprofile_data
--------------------------+---------------------
 Reporter:  Ninos Ego     |       Owner:
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  1.5.5
Component:  XProfile      |     Version:  1.5.4
 Severity:  normal        |  Resolution:  fixed
 Keywords:                |
--------------------------+---------------------
Changes (by boonebgorges):

 * keywords:  reporter-feedback =>
 * status:  new => closed
 * resolution:   => fixed
 * milestone:  Awaiting Review => 1.5.5


Comment:

 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.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3949#comment:6>
BuddyPress <http://buddypress.org/>
BuddyPress