Primary xprofile field "name" does not synch wiht WP profile field "first and lastname"

[houdjiva]

i changed the primary profile field "NAME" to "pseudonyme ou nom d'activité", you remark accented characters in the fiel name.

When a new member sign up, the name in the primary field "NAME" doesn't synch with WP fields "first and last name", and when i edit my profile in the BP extented profile, WP fields "first and last name" emptied.

[slaFFik]

Hi @houdjiva,

Do you have "Profile Syncing => Enable BuddyPress to WordPress profile syncing" checked on Settings -> BuddyPress -> Options page in wp-admin area?

You wrote that "WP fields "first and last name" emptied.", but are BuddyPress NAME field values saved and saved correctly?

[houdjiva]

Hi @slaFFik,
Yes, profile syncing is enable in wp admin area, and when WP fields "first and lastname" emptied, buddypress NAME field values saved correctly.

[houdjiva]

The problem is resolved when i named again the Bp field NAME whith a word without special caractère. Please do the test you will find out the bug. Please name again the field with a special letter

[slaFFik]

The problem is with a single quote:

'

Having it in Name field breaks our sync.
So I can confirm the bug.

@houdjiva - thanks for your report!

[houdjiva]

You're welcome

[boonebgorges]

This issue appears to stem from the fact that we store slashed data, and we do weird things with the Full Name field.

• BP<->WP profile syncing takes place in xprofile_sync_wp_profile(), which uses bp_xprofile_fullname_field_id() -> bp_xprofile_fullname_field_name() -> BP_XPROFILE_FULLNAME_FIELD_NAME. This constant is set in BP_XProfile_Component::setup_globals(), by fetching the 'bp-xprofile-fullname-field-name' option. This option is stored with slashes (blamepeatling). In [3643], we noticed that this was causing letters to be escaped on the settings panel, and decided that stripping slashes when defining the constant was the right way of fixing the problem. See #2968.

• But bp_xprofile_fullname_field_name() does a direct SQL query without adding slashes. So it doesn't find the fullname field, which wreaks all sorts of havoc.

The simple solution, I guess, is 7317.diff​ - since we're querying for data that we know to be slashed, we should actively look for slashed data. A better solution would be to stop storing slashed data, but this will be next to impossible to fix. Ping @djpaul - you have thought about this, and maybe you have a better idea.

[DJPaul]

This patch is a good fix for this problem, but let's add a comment linking back to this discussion or something.

I might be interested in revisiting the slashed stuff next year. I am sure there is an existing ticket with my thoughts from a few years ago, but off the top of my head, I think the fix to all of that involves a huge amount of work, which I'd break down into these steps:

1. Update all code to not store slashes, nor expect slashes in the output -- basically, making sure everything is done properly.
   • This'll involve changes to the low-level insert/update functions, as well as checking the input sanitisation everywhere, including removing lots we have hooked to filters.
   • The goal being everything working fine on a new install.
2. Run the new code on an existing site's content, audit everything, fix backwards compatibility.
   • This'll probably involve hooking stripslashes to output filters, etc.

There are likely complications around search/query fields. We may have to migrate certain tables' columns (strip the slashes and reinsert) to support things like this. The idea of migrating the slashes in the DB via an upgrade routine sounds pretty unscalable to do all the time, but maybe we could ship a WP-CLI tool or similar to do this.

[boonebgorges]

In 11243:

Improve slash handling for Full Name field name.

The Full Name field name is stored as slashed data, so we must query it
as slashed data too. Otherwise, the query misses in certain cases,
resulting in wacky behavior when syncing WP and BP profile fields.

Fixes #7317.