[buddypress-trac] [BuddyPress Trac] #7317: Primary xprofile field "name" does not synch wiht WP profile field "first and lastname"

[buddypress-trac]

#7317: Primary xprofile field "name" does not synch wiht WP profile field "first
and lastname"
------------------------------+------------------
 Reporter:  houdjiva          |       Owner:
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  2.8
Component:  Extended Profile  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |
------------------------------+------------------
Changes (by boonebgorges):

 * keywords:   => has-patch


Comment:

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

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7317#comment:7>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac