Skip to:
Content

Opened 2 years ago

Closed 14 months ago

Last modified 3 months ago

#3725 closed defect (bug) (fixed)

Primary extended profile field name change not working

Reported by: ddolenc Owned by:
Milestone: 1.6 Priority: normal
Severity: major Version: 1.5
Component: XProfile Keywords:
Cc: chrisclayton, JDoe_

Description

By definition the primary extended profile field in the Base group is "Name". If "Name" is changed in the dashboard using BuddyPress > Profile Fields to something else (for example "First and Last Name"), the field values are not saved as entered. Instead, he username is saved in the database for this field.

Change History (13)

comment:1 boonebgorges2 years ago

  • Keywords reporter-feedback added
  • Milestone changed from Awaiting Review to Future Release

I can't reproduce this on my installations.

Is your installation an upgrade from an earlier version of BuddyPress?

comment:2 shastaw2 years ago

I have the same problem. Here are my parameters:

I upgraded to BuddyPress 1.5 from a much earlier version.

I changed the primary field's name from "Name" to something custom, let's say "New Name".

Saving changes to a profile WITHOUT changing the "New Name" gives the red message "There was a problem updating some of your profile information, please try again." and adding debugging messages shows it is choking on the primary field.

If I change the value in "New Name" it will give the green bar of success, but the "New Name" value continues to reflect the original value -- the username.

Changing the primary field back to "Name" in the admin interface corrected the problem and I can now save changes to the primary field as well as everything else.

I'm using 3.2.1 Wordpress.

Last edited 2 years ago by shastaw (previous) (diff)

comment:3 Steve Holland2 years ago

  • Severity changed from normal to major

I can replicate this also.

  • WP is always updated within a week or two.
  • I installed BP 1.2 (it was the latest version when installed).
  • After installed I renamed the primary "Name" field to "Full Name".
  • I recently upgraded to BP 1.5.2
  • I found that users could no longer update this field and it kept getting overwritten with the username and Wordpress profile field data would be deleted (First Name, Last Name, Display Name).
  • New registrations, the primary field "Full Name" would be completely ignored and whatever username they used would overwrite it.

The fix was (having already upgraded) to rename my primary field from "Full Name" back to "Name".

comment:4 nullvariable2 years ago

Seems my issue is the same/related. Debug info attached to: #3925

comment:5 chrisclayton2 years ago

  • Cc chrisclayton added

Just to add, This is an important fix that needs to be in 1.6 as it breaks the toolbar "howdy" button.

comment:6 DJPaul2 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Future Release to 1.5.4

As we're getting quite a few reports about this, I'm moving the ticket to an earlier milestone.

comment:7 boonebgorges2 years ago

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

comment:8 johnjamesjacoby2 years ago

  • Milestone changed from 1.5.4 to 1.6

Moving this to 1.6 to get 1.5.4 out.

comment:9 boonebgorges2 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [5778]) Use field_id 1 when checking for existing fullname in bp_core_get_user_displayname() fallback, to avoid mismatches in bp-xprofile-fullname-field-name site option.
Don't overwrite bp-xprofile-fullname-field-name and bp-xprofile-base-group-name during upgrade if they're already populated.
Fixes #3725

comment:10 boonebgorges2 years ago

(In [5779]) Use field_id 1 when checking for existing fullname in bp_core_get_user_displayname() fallback, to avoid mismatches in bp-xprofile-fullname-field-name site option.
Don't overwrite bp-xprofile-fullname-field-name and bp-xprofile-base-group-name during upgrade if they're already populated.
Fixes #3725

comment:11 JDoe_19 months ago

  • Cc JDoe_ added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Actually, Ticket#3768 describes the problem I'm encountering accurately. However, it is duped to ticket#3725 and hence re-opening this one.

I have WP 3.4.2 and BuddyPress 1.6.1 but still see the problem.

I also checked the files mentioned in the diff attached to this ticket and see that I have the updated changes.

Here is the screencap:
http://i45.tinypic.com/91a0pl.jpg

https://wordpress.org/support/topic/buddypressmultisite-name-required-being-set-to-username

Last edited 19 months ago by JDoe_ (previous) (diff)

comment:12 boonebgorges14 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

JDoe_ - it sounds like this is a separate issue, related to registration rather than name changes. Please open a separate ticket with detailed instructions on reproducing your issue.

comment:13 ircbot3 months ago

This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.

Note: See TracTickets for help on using tickets.