The xProfile "Name" Field

[needle]

This is a follow-up to #7162, where @imath said:

The Name field is something we'll probably need to talk about in the future. For 8.0.0, if it's generating some confusion we can eventually rename it for something more like "Display name". But I believe this should be discussed/fixed in another ticket because we are not using these new Profile types to generate it.

So I'm opening this ticket because the way that the xProfile "Name" Field syncs with the WordPress User Fields still confuses me...

Currently, it seems to be the case that:

• When editing the content of the xProfile "Name" Field, BuddyPress syncs to both the WordPress User "Nickname" Field and the "Display Name" Field.
• When only the WordPress User "Nickname" Field is changed, the xProfile "Name" Field is not updated.
• When only the WordPress User "Display Name" is changed, the xProfile "Name" Field is updated.

This asymmetrical sync can result in strange behaviour when just the WordPress user "Display Name" Field is changed in WordPress admin - because resaving the xProfile "Name" Field then overwrites the WordPress User "Nickname" Field.

I don't have a clear idea of what the expected behaviour should be - hence this ticket.

[needle]

FWIW, I see that *mutter* BuddyBoss *mumble* has its own "Display Name Format" setting that governs how sync occurs between xProfile Fields and the User "Display Name" Field. Perhaps backporting that idea has merit?

[imath]

Hi @needle

I agree we need to improve the xProfile "Name" / WP Display Name sync feature. But another setting like the fork you're talking about, should be avoided. BuddyPress does not copy but leads by example ;)

Who wants to jump in and suggest ideas, or better a patch. I'll be happy to help progress occurs on this ticket.

[needle]

@imath I'm adding this here because it seems to fall into the scope of "xProfile Field to/from WordPress User Field" syncing process.

It seems that adding "First Name" and "Last Name" xProfile Fields (of type wp-textbox and matched to their corresponding WordPress User Fields) to the "Signup Fields" Profile Group does not result in them populating the "First Name" and "Last Name" WordPress User Fields when users signup.

The xProfile Fields do have values in the wp_bp_xprofile_data table, but since they are never shown in BuddyPress admin (as ​noted in the discussion on the original ticket) it is impossible to propagate their values to their corresponding WordPress User Fields.

The "Website" wp-textbox and "Biography" wp-biography xProfile Fields do get populated on signup however - and do not have entries in the wp_bp_xprofile_data table.

[imath]

Thanks for your feedback. I’ll look at what’s going wrong during the signup process. It seems weird because I did check this part earlier. Just a note: unlike the BP Name/ WP display name sync feature, these field types are only using the wp_usermeta table to store the data, so it’s a regular behavior not to have the data duplicated into the bp XProfile data table.

[imath]

I've just tested and wasn't able to reproduce:

it seems that adding "First Name" and "Last Name" xProfile Fields (of type wp-textbox and matched to their corresponding WordPress User Fields) to the "Signup Fields" Profile Group does not result in them populating the "First Name" and "Last Name" WordPress User Fields when users signup.

When the user signs up and activate his account (or have his account activated by the Admin): First and last name value are saved into the WP_User->data->first_name & WP_User->data->last_name field.

If I go to the just signed up user's profile tab on front-end, Profile fields are including the first and last name with their corresponding values.

So to me everything is fine :)

[needle]

@imath I'm surprised you can't reproduce. Here's what I see on a completely fresh WordPress 5.9-alpha-51860 and BuddyPress Revision 13114. Nothing configured beyond the defaults except to add "First Name" and "Last Name" Fields mapped appropriately:

I filled out the Registration Form like this:

Then stepped through activation process. For me, this results in "First Name" and "Last Name" as xProfile data:

And The WordPress User Profile populated like this:

The result leaves the "First Name" and "Last Name" xProfile data orphaned with no way to sync it to the WordPress User "First Name" and "Last Name" except via code.

Can you double-check your test please? Thanks!

[needle]

@imath What's happening is that xprofile_sync_wp_profile() extracts $fullname, $firstname and $lastname from the xProfile "Display Name" Field, then overwrites "First Name" and "Last Name" during the bp_core_signup_user action.

FWIW here's the data just before calling bp_update_user_meta() and wp_update_user():

[method] => xprofile_sync_wp_profile
[user_data] => stdClass Object
  (
    [ID] => 2
    [user_login] => nobody
    [user_pass] => ########
    [user_nicename] => nobody
    [user_email] => nobody@haystack.co.uk
    [user_url] =>
    [user_registered] => 2021-09-27 11:45:15
    [user_activation_key] =>
    [user_status] => 2
    [display_name] => nobody
  )

[display_name from xProfile] => Displayname
[first_name from user_meta] => Christian
[last_name from user_meta] => Surname

[$fullname from xProfile] => Displayname
[$firstname extracted from $fullname] => Displayname
[$lastname extracted from $fullname] =>

This explains why I'm seeing what I'm seeing - but not why it works for you.

[imath]

@needle probably because the Sync option wasn't on 😬. I'll check again, thanks for the details you provided 💪

[imath]

@needle thanks for insisting 😅. I confirm I was able to replicate the issue. I believe this one should be fixed asap in 9.2.0.

​8568.patch should fix the issue, can you test and confirm?

Note to self: I'll need to test the patch on multisite!

[imath]

Ah! This one is tough. It actually does not fix it. It'll need more work to be fixed.

[imath]

Ouch I see what was wrong. My bad 😆 ​8568.2.patch should fix it!

[needle]

@imath Latest patch works for me in both single and multisite instances. Thanks for the quick turnaround on this!

[needle]

With regard to the original conundrum of asymmetric sync - my current $0.02 is that BuddyPress could offer separate xProfile Fields for both "Nickname" and "Display name publicly as" which have an automatic one-to-one correspondence with the respective WordPress User Fields.

It would most likely mean that the xProfile "Display name publicly as" Field would have to mirror the way the WordPress User Field works, i.e. populating dynamically from other xProfile Fields via Javascript. Plus some thought about how to transition from the existing mapping schema to a new one.

[imath]

Thanks a lot for your tests @needle and opinion about the Name sync feature 👍

[imath]

I was wondering what was the purpose of the nickname and found this on ​stackexchange

Display name is selectable between the user's username, first name, last name, first/last, or last/first, or nickname. The nickname exists to give you an option to set display name to something other than your username or real name.

Do we have an idea why we are syncing the nickname with the BP Name field ?

[imath]

In 13121:

xProfile: prevent the Name field to override WP Field Types on signup

When the BP xProfile Base Name field synchronization with the WordPress Display Name field is on, we need to make sure values of potential first and/or last name fields using the xProfile WP Field Type are not overridden by this synchronization.

Props needle

See #8568 (trunk)

[imath]

In 13122:

xProfile: prevent the Name field to override WP Field Types on signup

When the BP xProfile Base Name field synchronization with the WordPress Display Name field is on, we need to make sure values of potential first and/or last name fields using the xProfile WP Field Type are not overridden by this synchronization.

Props needle

Fixes #8568 (branch 9.0)

[imath]

[13122] fixed the issue about #comment:3. Let's reopen this ticket to keep on working on improving the Base Name xProfile Field sync with the WP nickname field. Because after looking more deeply into it, it's how it is synchronized: first the nickname & then the Display Name.

[imath]

We won't have time to work on these during 10.0.0, sorry about it.

[imath]

We'll work on it during next development cycle.