[buddypress-trac] [BuddyPress] #3725: Primary extended profile field name change not working
buddypress-trac at lists.automattic.com
buddypress-trac at lists.automattic.com
Wed Feb 1 21:12:14 UTC 2012
#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:
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
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
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
- In BP 1.2.x, you change the name of your profile field from 'Name' to
- That saves the value to sitemeta, meta_key bp-xprofile-fullname-field-
- 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>
More information about the buddypress-trac