[buddypress-trac] [BuddyPress Trac] #5619: Allow user to edit WordPress Profile when the Extended Profiles component is disabled

[buddypress-trac]

#5619: Allow user to edit WordPress Profile when the Extended Profiles component
is disabled
-------------------------+------------------------------
 Reporter:  r-a-y        |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Members      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  ux-feedback  |
-------------------------+------------------------------

Comment (by boonebgorges):

 >  The WordPress profile fields barely every see any updates so I disagree
 with this argument.

 OK, fair enough.

 I'm a bit confused regarding the thrust of the rest of your argument. The
 bug, as it's introduced in this ticket, is as follows: when xprofile is
 disabled, we show a 'profile-wp' template when visiting
 `members/membername/profile/`. This template includes the following WP
 profile values: `display_name`, `user_description`, `user_url`, `jabber`,
 `aim`, and `yim`. And the issue at hand is that while these fields can be
 viewed on the BP front end, they cannot be edited on the BP front end. So
 the fix would be to add support for editing these fields on the front end.

 The points being pressed by Azinfiro seem to be more general: some of the
 WP profile fields are widely used, and would if better supported in BP be
 helpful to many other plugins, and so should get full BP support. To my
 mind, that suggests making them *always* available somehow - not simply as
 a fallback for when xprofile is disabled. Another way of putting the same
 point: if these things are important enough to display when xprofile is
 turned off, then they're important enough to display when it's turned on.
 But moving in this direction introduces all sorts of issues (such as:
 optional syncing between the core fields and corresponding BP xprofile
 fields; a UI for toggling the display of certain core fields; etc).

 My personal opinion is that WP core profile fields are *not* in fact so
 widely used or of so much value, and that it's not worth taking away from
 our limited development resources to build a large integration. But I
 could be convinced otherwise with the right evidence.

 I don't know if this qualifies as your "on-point reply", but I'd like to
 put the ball back in your court and ask the following: what exactly is it
 that you want to be happening here? What would better integration between
 the field types look like? Can you sketch the situations? What happens
 when xprofile is enabled/disabled? Is there syncing happening, or are the
 profiles separate? How does this look from the site admin point of view?

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