#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: | Extended Profile | 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 (15)
#1
@
13 years ago
- Keywords reporter-feedback added
- Milestone changed from Awaiting Review to Future Release
#2
@
13 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.
#3
@
13 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".
#5
@
13 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.
#6
@
13 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.
#7
@
13 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.
#9
@
13 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
#10
@
13 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
#11
@
12 years 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
#12
@
12 years 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.
This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.
11 years ago
#14
@
8 years ago
Hi,
I am using:
Fresh and New Install
WP 4.4.2
BP 2.5.2
Multisite
BP_ENABLE_MULTIBLOG = true
Sync between WP and BP activated in all blogs
We changed the primary Xprofile field name to "Full Name", using the primary blog.
When we update the primary BP field, using the backend or frontend of a different blog in the network, the primary field is not updating the WP name, last name and display name.
But, if we try to update the field using the primary blog, the sync works fine.
Bottom line: the profile sync is not working in every blog of the network and the problem persists according to my experience.
WORKAROUND:
I had to update the BP xprofile field_1 (in my case from Name to Last Name) from every blog, even if the BP settings was displaying the correct field name.
Thanks,
I can't reproduce this on my installations.
Is your installation an upgrade from an earlier version of BuddyPress?