Skip to:
Content

BuddyPress.org

Opened 3 years ago

Last modified 3 months ago

#8568 reopened enhancement

The xProfile "Name" Field

Reported by: needle's profile needle Owned by: imath's profile imath
Milestone: 14.0.0 Priority: normal
Severity: normal Version: 1.0
Component: Extended Profile Keywords: needs-patch
Cc:

Description

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.

Attachments (2)

8568.patch (8.7 KB) - added by imath 3 years ago.
8568.2.patch (8.8 KB) - added by imath 3 years ago.

Download all attachments as: .zip

Change History (24)

#1 @needle
3 years ago

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?

#2 @imath
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 10.0.0

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.

#3 @needle
3 years ago

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

#4 @imath
3 years ago

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.

#5 @imath
3 years ago

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 :)

#6 @needle
3 years ago

@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:

https://i.postimg.cc/qqcVt8RV/Screenshot-2021-09-27-at-12-07-41.png

I filled out the Registration Form like this:

https://i.postimg.cc/L81kjNS1/Screenshot-2021-09-27-at-12-09-12.png

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

https://i.postimg.cc/fydXYbnh/Screenshot-2021-09-27-at-12-09-56.png

And The WordPress User Profile populated like this:

https://i.postimg.cc/G3PmTD6m/Screenshot-2021-09-27-at-12-10-27.png

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!

#7 @needle
3 years ago

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

Last edited 3 years ago by needle (previous) (diff)

#8 @imath
3 years ago

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

@imath
3 years ago

#9 @imath
3 years ago

  • Keywords has-patch needs-testing added; needs-patch removed
  • Milestone changed from 10.0.0 to 9.2.0
  • Version set to 8.0.0

@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!

#10 @imath
3 years ago

  • Keywords needs-patch added; has-patch removed

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

@imath
3 years ago

#11 @imath
3 years ago

  • Keywords has-patch added; needs-patch removed

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

#12 @needle
3 years ago

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

#13 @needle
3 years ago

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.

#14 @imath
3 years ago

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

#15 @imath
2 years ago

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 ?

#16 @imath
2 years ago

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)

#17 @imath
2 years ago

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

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)

#18 @imath
2 years ago

  • Keywords needs-patch added; needs-testing has-patch removed
  • Milestone changed from 9.2.0 to 10.0.0
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 8.0.0 to 1.0

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

#19 @imath
2 years ago

  • Milestone changed from 10.0.0 to Up Next

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

#20 @imath
15 months ago

  • Milestone changed from Up Next to 12.0.0

#21 @imath
8 months ago

  • Milestone changed from 12.0.0 to Awaiting Contributions

#22 @imath
3 months ago

  • Milestone changed from Awaiting Contributions to 14.0.0
Note: See TracTickets for help on using tickets.