[buddypress-trac] [BuddyPress] #3725: Primary extended profile field name change not working

[buddypress-trac at lists.automattic.com]

#3725: Primary extended profile field name change not working
--------------------------+--------------------
 Reporter:  ddolenc       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  1.5.4
Component:  XProfile      |     Version:  1.5
 Severity:  major         |  Resolution:
 Keywords:                |
--------------------------+--------------------

Comment (by boonebgorges):

 OK, I have finally managed to figure out what's going on here. A couple of
 unfortunate things have combined to bring about this icky bug.

 In BP 1.5, we moved most of our BP settings to be stored in individual
 blog options tables, instead of in sitemeta, through the use of the
 bp_x_option() functions. (The main purpose of this is to allow for BP
 multi-network setups.)

 Furthermore, in BP 1.5 we changed the way that the required Name xprofile
 field is named. It used to be that the primary storage space for this
 field name was in sitemeta (keyed as bp-xprofile-fullname-field-name)
 instead of in wp_bp_xprofile_fields with all of the other fields. In BP
 1.5, we changed it so that field_id 1 works in the same way as all other
 fields. bp-xprofile-fullname-field-name is kept for backward compatibility
 in some places; the xprofile_fields value is then synced manually to the
 bp-xprofile-fullname-field-name meta.

 Finally, when the installation scripts for each component were moved into
 a single schema file for purposes of the installation wizard
 (http://buddypress.trac.wordpress.org/changeset/2863 and the introduction
 of bp-core/admin/bp-core-schema.php), Andy failed to do a proper check for
 the existence of a value for bp-xprofile-fullname-field-name before simply
 overwriting it. I guess the logic was that you would only install the
 component once. (That seems incorrect, though, because we use those
 functions for updating the DB schema, using dbDelta())

 Anyway, what would happen as a result of all of this is something like the
 following:
 - In BP 1.2.x, you change the name of your profile field from 'Name' to
 'Your Name'
 - That saves the value to sitemeta, meta_key bp-xprofile-fullname-field-
 name
 - You upgrade BuddyPress to BP 1.5.x
 - You run through the installation wizard. The database upgrade step calls
 bp_core_install(), which calls bp_core_install_extended_profiles(), which
 does bp_update_option( 'bp-xprofile-fullname-field-name', _x( 'Name',
 'XProfile fullname field name', 'buddypress' ) );
 - If you're on Multisite, then bp_update_option() in the previous step
 will save the new value 'Name' to your blog options, while 'Your Name'
 remains in wp_sitemeta at bp-xprofile-fullname-field-name
 - At the same time, when BP detects your existing xprofile fields, it uses
 the 'Your Name' label to identify field 1. Thus, there is a mismatch
 between what is in your options table ('Name', which is scooped into
 $bp->site_options), and wp_bp_xprofile_fields.
 - Now, when bp_core_get_user_displayname() runs, it tries to look up your
 name like this http://buddypress.trac.wordpress.org/browser/trunk/bp-
 members/bp-members-functions.php#L410, finds nothing, and so then
 overwrites your xprofile data with your WP display_name.
 - In most cases, your WP display_name will be the *same* as your xprofile
 Name, which is probably why we haven't noticed the problem. But in some
 cases it won't (such as when syncing is disabled). In those cases, you see
 the problem described in this and related tickets.

 Unfortunately for those who have experienced the problem, this does indeed
 mean that the display names in question have been lost, and will have to
 be reentered by users.

 We do need to fix some stuff in BP. I think that the two following fixes
 will do it:
 - In the installation wizard, make sure you check for the existence of a
 value for bp-xprofile-fullname-field-name before overwriting it.
 - In bp_core_get_user_displayname(), instead of looking up the current
 user's existing display name using $bp->site_options['bp-xprofile-
 fullname-field-name'], just use the field id 1.

 I'll have to do some experimentation to make sure that this will indeed
 solve the problem, which I'll try to do later in the week. In the
 meantime, I wanted to write up my findings so that I wouldn't forget, and
 to get any feedback.

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