Allow user to edit WordPress Profile when the Extended Profiles component is disabled

[r-a-y]

An interesting point was raised here:
http://buddypress.org/support/topic/wp-profile-fields-not-editable-in-bp-profile/

We already display the WP profile when the Extended Profiles component is disabled, but don't allow users to edit it.

On the contrary, bbPress allows the user to edit WP's profile:
eg. example.com/forums/users/USERNAME/edit/

I would say as a follow-up to #3335, we could copy bbPress' user edit profile code and use it as a fallback if BP's own Extended Profiles component is disabled.

If we were to go this route, we'd also have to consider where this page should live. /members/USERNAME/profile/edit/ would be the most appropriate, but we'd also have to consider the generic /members/USERNAME/settings/ page as well.

Thoughts?

[Azinfiro]

...we could copy bbPress' user edit profile code and use it as a fallback if BP's own Extended Profiles component is disabled.

Maybe not surprisingly, I strongly support this.

If we were to go this route, we'd also have to consider where this page should live.

For the sake of consistency with Extended Profiles, I agree that /members/USERNAME/profile/edit/ would be more appropriate, but the profile would be so light-weight without custom fields that I think having both an edit and a settings page for editing your profile would become redundant, even if they inherently serve slightly different purposes.

[boonebgorges]

members/username/profile/edit seems like the right URL to me. That said, it will be confusing (and arguably is already confusing with xprofile turned on) to have email and password located at Settings. Maybe crosslinks between the two?

[DJPaul]

I disagree; I think our energy is best spent in other areas. Maintaing two sets of profile field editing/updating code sounds a bit mad. :)

I'd rather know why someone would want to be able to use and display and edit WP profile fields, but not BP profile fields. Ours are obv much better. :)

[Azinfiro]

DjPaul and boonebgorges, can I ask you to reply directly to my arguments in the BuddyPress Support topic?

Maintaing two sets of profile field editing/updating code sounds a bit mad.

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

I'd rather know why someone would want to be able to use and display and edit WP profile fields...

The WordPress profile fields are extensively used throughout various themes, e.g. post author bios, display names, real names. The few WordPress profile fields you have are quite reasonable and are not immediately replaceable by BuddyPress Extended Profiles fields (think display name selection).

Finally, supporting WordPress profile fields would increase the independence of each BuddyPress module as you would no longer rely on the Extended Profiles module, thereby progressing towards a truer modular BuddyPress.

As I started out by saying, I would very much like an on-point reply to these arguemnts along with the arguments in the corresponding BuddyPress Support thread.

Thank you.

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

[Azinfiro]

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

I don't see your point since they're already displayed exclusively when Extended Profiles is disabled so it has already been decided that they aren't.

The points being pressed by Azinfiro seem to be more general...

I really don't think they are. I'm concerned with the petition put forward in this ticket to enable editing the WordPress profile fields in the BuddyPress front-end. Nothing more.

Can you sketch the situations?

When Extended Profiles is disabled the 'profile-wp' template you refer to is displayed and all WordPress profile options are accessible at either members/username/profile/edit or members/username/settings.

When Extended Profiles is enabled the WordPress template is not displayed and all WordPress profile options are still accessible at either location.

...I could be convinced otherwise with the right evidence.

This request is a bit murky so you will have to be more specific.

The user bio along with contact information is often displayed underneath posts. The number of ​plugins offering this function should be sufficient evidence that it's widely used, as are names and nicknames (I hopefully won't have to prove that).

Jabber, aim, and yim are no longer supported in the back-end, so I won't argue for making these editable in BuddyPress.

Distribution of the resources required to do this is obviously up to the developers, but I want to reiterate that bbPress already offers the option to edit the WordPress fields as well as display them.

[boonebgorges]

Thanks for the update, Azinfiro. I guess I misinterpreted your earlier request for a rebuttal to your arguments. I thought you wanted justification for why further integration wasn't being offered. I guess I interpreted it that way because I don't think anyone on this thread has disagreed that we should add support for editing these fields, so I wasn't sure who you were arguing against. Maybe this?

I disagree; I think our energy is best spent in other areas. Maintaing two sets of profile field editing/updating code sounds a bit mad. :)

I think here DJPaul was referring to keeping two sets of email/password fields, not to the more general prospect of allowing WP fields to be edited.

So I guess we're all on the same page in terms of what happens in this ticket? Namely, we add support for editing WP fields when xprofile is disabled. (I've gotten a bit lost over the last few posts.) It just remains to be determined what the URL should be.

[Azinfiro]

Haha alright, it's good that we're on the same page again.

I don't think DjPaul was referring just to the email and password fields though:

I'd rather know why someone would want to be able to use and display and edit WP profile fields, but not BP profile fields. Ours are obv much better. :)

Also, just to be clear, I argue for access to WordPress profile field options in BuddyPress when Extended Profiles is enabled for the reasons I mentioned above.

[boonebgorges]

Also, just to be clear, I argue for access to WordPress profile field options in BuddyPress when Extended Profiles is enabled for the reasons I mentioned above.

OK. If this is something you want to pursue, let's do it in a different ticket. (Please also search Trac for existing tickets on the subject; see eg #3335.) I have misgivings about it, but I don't want those misgivings to hold up this ticket.

[DJPaul]

Namely, we add support for editing WP fields when xprofile is disabled.

I still don't think this is worth our time, but if anyone wants to contribute a patch (or part of a patch), I don't feel strongly enough to continue arguing against its exclusion. Moving to Future Release.

[slaFFik]

I agree with Paul, and have nothing to add more. On standard WordPress install every user can edit WordPress profile fields on /wp-admin/profile.php page.

As no one in 2 years showed interest in this ticket, I'm closing it as wontfix.
If anyone wants to implement this - feel free to reopen or create a separate ticket.