[buddypress-trac] [BuddyPress Trac] #5619: Allow user to edit WordPress Profile when the Extended Profiles component is disabled
noreply at wordpress.org
Tue Jun 24 21:53:52 UTC 2014
#5619: Allow user to edit WordPress Profile when the Extended Profiles component
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/>
More information about the buddypress-trac