Access Member Profiles from the Admin Backend

[svenl77]

As an admin of a WordPress install I can access all user data from the backend under User/All User/Edit User.

But to access the BuddyPress Member Profile Data I need to switch the user to the user I want to edit and then go to the Frontend Member Profile to make my changes.

The idea on the contributors day @WCEU was to add the BuddyPress Profile Fields below the WordPress user profile fields in the backend.

Use the "show_user_profile" hook to add this fields. and "edit_user_profile_update" hook to save the data with bp_update_user_meta but not as user meta data.

After more deeply thinking about this topic and doing some testing, I think this can cause conflicts in some cases.

An example of many others could be WooCommerce.

The Shipping Address fields are stored as user meta data.

I wrote a plugin to sync woocommerce user meta data with buddypress xprofile fields and make all woocommerce relevant user meta data available in your BuddyPress Profiles.

In this situation, the WooCommerce Shipping address would be displayed twice in the User Profiles in the Backend if we just add all BuddyPress xprofile fields to the WordPress user profiles.

We could add a check if the field exists and only add it if not, I do not know if this could cause other conflicts.

Another idea could be to sync all user meta data with buddypress and created xprofile fields from user meta and vice versa.

There could be a check box in the buddypress admin “Keep my WordPress user data and BuddyPress xprofile data synced”.

In this case all the sync code in other plugins could be removed. But again, I don’t know if this is a good idea.

I think I need some thoughts from other developers before I start writing code.

[boonebgorges]

This is a cool idea.

My wish for the long term is for us to have a truly robust way for admin to manage BP member data in the dashboard, similar to our Groups and Activity panels. However, this is going to be complicated, because of potential confusion with the existing Users panel created by WordPress.

So, in the meantime, I think that the current idea - adding xprofile fields to user-edit.php - is a good idea.

Use the "show_user_profile" hook to add this fields. and "edit_user_profile_update" hook to save the data with bp_update_user_meta but not as user meta data.

This sounds right. I imagine we wouldn't need to duplicate too much code; we could probably use existing templates for this (profile-loop.php).

I'm not convinced that the conflicts you suggest are such a big deal. Your plugin for WooCommerce is the only plugin I've ever heard of that does this kind of syncing. So it might be a non-issue in most cases. Even so, what's the danger here? If you have two-way sync built into your plugin, then updating one of the sets of duplicate fields would simply force a sync to the other one. And if you're worried about confusing your users with having duplicate fields, then your plugin could select to hide certain fields from this page. (We could offer an 'exclude' array for BP fields on this page, and allow plugins to add their fields to that array.)

I'm curious to hear what other developers think about the general idea.

[DJPaul]

Interesting to consider if we should allow the end user to edit their own profile fields through this new screen; I think I'd like us to keep it to the front end only, as it is now , but I think showing the profile fields on user-edit.php for *admins* is a good idea, as long as we can do it in a way that's compatible with any custom fields added by plugins that extends BuddyPress, and without duplicating a ton of validation/save code.

[boonebgorges]

Interesting to consider if we should allow the end user to edit their own profile fields through this new screen; I think I'd like us to keep it to the front end only, as it is now , but I think showing the profile fields on user-edit.php for *admins* is a good idea, as long as we can do it in a way that's compatible with any custom fields added by plugins that extends BuddyPress, and without duplicating a ton of validation/save code.

Yes, I think it's sensible that this would be a feature focused on admins rather than regular users. Maybe it's something that could be disabled for non-admins by default, but could be enabled with a filter or something like that. (Seems like implementing it this way would take no extra work, so we might as well.)

without duplicating a ton of validation/save code.

svenl77 - If you start patching this, and you discover that the structure of the current display/validation logic requires you to reproduce lots of code, please feel free to suggest improvements to the existing code so that it'll be more portable.

[imath]

I know @svenl77 is/will work(ing) on this, but i was too curious about what could look like BuddyPress Extended profiles in WordPress Edit User Administration screen.

So i wrote some draft code on my development config. First i began by using the edit_user_profile hook to load the different BuddyPress groups of fields directly into the user-edit.php page.
1- This is a screen capture the ​user-edit page

Then i thought, depending on the number of profile fields, this can be a huge page to scroll!! So i've edited my draft to add a navigation using using the edit_user_profile hook and some extra css just under the "Edit User" title, and write some code to create a new user page to load in it the groups of fields.
2- This is a screen capture of the ​navigation in the user-edit.php page.
3- This is a screen capture of the ​community profile page

Then i thought, as a community administrator, having the ability to edit the fields is great, but i'd like to have more infos/actions available for this community profile such as :

• a way to spam/unspam user,
• the day he registered,
• some stats about his activity in the community,
• a way to give plugins the opportunity to add some new actions in this profile.

So i wrote some other draft code to build an alternative community profile using the same logic than the activity/group Administration edit screen.
4- This is a screen capture of this alternative ​community profile page

So imho, i think we should use a different area from the user-edit.php page like point 3 or 4. I like point 4 as it would give a way to spam/unspam a user from the Administration in case WordPress is not configured in multisite, plugins could add a specific metabox, for instance bbPress could inform about the number of posts/replies made by the user etc.

If you think it's interesting, i'll attach patch(es) to this ticket using the different options or the one you think it's best.

[imath]

Following up on this ticket, I've built a patch (5197.diff) I wish to have your opinion on. I may have extended the scope of the ticket.

In my latest comment, I've described four options, this patch introduces some improvement on option 4 :

• each group of profiles has his own metabox
• the metabox showing the avatar includes a link to delete the avatar, in case the administrator need to moderate a non appropriate avatar for the audience he targets.

This patch will add his main code into bp-xprofile-admin.php, it includes some new css rules in /bp-xprofile/admin/css/admin.css to style the profile navigation to "toggle" between community profile/ WordPress profile. I've tested it and most things seems to work fine.

I haven't included the visisbility settings and "clear" selected options features, as it will require to load some extra javascript.

This a screen capture of ​this Profile page

Some thoughts :
1/ As, I've added some functions not related to xprofile, I really think this code should be best located in new files in the members component :

• php part /bp-members/bp-members-admin.php
• js and css /bp-members/admin/css and /bp-members/admin/js

This way in case the xprofile component is not active some actions could still be available. And the new file bp-members-admin.php can host other functions in order to list pending registrations for example.

2/ It will surely need to make sure the spam/unspam process is ok
For instance it works fine on single site, but on multisite, if spaming from the profile page, then unspaming from the WordPress users.php page, the user is unspamed for WordPress but not for BuddyPress. see #5275
Having this feature can help to help Administrators to spam/unspam user in a non multisite config see #5113

3/ I had to set the buddypress()->displayed_user datas as some xprofile template functions do not have a user_id argument and use bp_displayed_user_id() in their code.

4/ Having this kind of UI can be interesting if one day, a function like bp_is_active_for_user() or bp_current_user_can( 'component' ) is added. Administrators would be able to manage a user's capacities from there.

[ubernaut]

this looks very awesome. i agree with adding more built in user stats and prefer the second variation of the community profile you posted. i will try to test this out as soon as i can make some time. thanks imath!

[boonebgorges]

Wow, this really does look amazing.

I'll take some time soon to dig through the patch a bit more thoroughly. At a glance it looks good.

I really think this code should be best located in new files in the members component

We should do both. In bp-members, you should have the code that adds the admin page and sets up some of the default metaboxes (Status, Stats). Include an action hook just after the bp-members section has been set up. Then, in bp-xprofile, hook to that action and register the bp-xprofile-specific metaboxes.

[imath]

Replying to boonebgorges:

Wow, this really does look amazing.
I'll take some time soon to dig through the patch a bit more thoroughly. At a glance it looks good.

Thanks Boone & @ubernaut :)

We should do both. In bp-members, you should have the code that adds the admin page and sets up some of the default metaboxes (Status, Stats). Include an action hook just after the bp-members section has been set up. Then, in bp-xprofile, hook to that action and register the bp-xprofile-specific metaboxes.

Yes : 100% agree, i thought of it today while working on registrations ;)

[johnjamesjacoby]

​5197.patch is a cleaned up up version of Imath's patch:

• More brackets per WordPress's coding standard
• Some verbiage changes

I love Imath's vision of allowing this to let us hook in roles and caps, etc... To be honest, after reviewing the patch, I'm comfortable committing this into trunk now and iterating on it through out the 2.0 cycle, putting this feature ahead of schedule, as it's likely to change quite a bit as we massage it.

[boonebgorges]

I'd personally like to see the split between bp-members and bp-xprofile stuff happen before this gets committed, as it's going to mean changes in function and class names from the existing patch. But yes, let's get this in soon and start iterating.

[hnla]

Cc

[imath]

Thanks for your feedbacks :)

I'll first restart from jjj's version of the patch and do the split between bp-members and bp-xprofile. i'll upload a new patch asap. Removing the commit keyword till that new patch.

[johnjamesjacoby]

Replying to imath:

I'll first restart from jjj's version of the patch and do the split between bp-members and bp-xprofile. i'll upload a new patch asap. Removing the commit keyword till that new patch.

Perfect. Looking forward to getting this into trunk asap.

[imath]

in 5197.01.diff, i've done the split, and doing so i realized that the admin profile without the profile fields was a bit weird as all the metaboxes are on the right side!

So i'm using a trick so that if the xProfile component is not active, then the stats are taking his place. As i'm also working on signups, i've realized that, on non-multisite configs, a non-activated account was on the list of users in the administration screen. So i've also added a check on user's status to eventually disable the status metabox and display a message to inform the user has not activated his account yet. FYI, in the signups patch i'm working on, i'm moving these signups in a new area and removing them from the users list.

Finally, i moved the different stats in each component, i think it's a better approach than having the list of bp_is_active checks.

If it's good for you, let's commit and start iterating ;)

[boonebgorges]

Looking excellent!

5197.02.diff has a couple minor changes:

1. I saw your hack for setting $bp->displayed_user->id. As you noted in the inline comments, this doesn't seem right. And I'm not sure if it'll affect plugins etc that are checking bp_is_user() and bp_displayed_user_id(). So, in a separate commit (which you'll see come through in a second), I've modified bp_get_the_profile_field_options() to accept a user_id param, and then modified the patch to use it. This seems much less hackish.

2. You were using the function touch_time() to render a non-js time field. This isn't relevant for our purposes, and in fact it's broken due to the internals of the function (which require either the $post or $comment global), so I removed the block.

3. Cleaned up inline docs to better match our standard.

I think it's ready to commit.

I do have a question: I see that you're filtering 'bp_get_the_profile_field_options_radio' and '_checkbox'. The only difference I could see is that you're adding a <br />. Is that right? Can't you do this with CSS?

[boonebgorges]

In 7762:

Add support for 'user_id' param to bp_get_the_profile_field_options()

This allows the use of this template function outside of the front-end Edit
Profile page, where $bp->displayed_user->id is defined.

See #5197

[imath]

Replying to boonebgorges:

I do have a question: I see that you're filtering 'bp_get_the_profile_field_options_radio' and '_checkbox'. The only difference I could see is that you're adding a <br />. Is that right? Can't you do this with CSS?

Yes, i made my life harder on this one. I will not include the two filters and will use a css rule instead. Thanks a lot for your help and feedback :)

[boonebgorges]

Ha ha, I know the feeling :) Make that fix and then commit it.

[johnjamesjacoby]

Some general feedback, either for a new patch, or after commit:

• Missing escaping in several places.
• Would like to shy away from dashicons specific classes.
• New stats functions for each component should have _get_ equivalents with filters on the results.
• New stats functions should probably be more robust, so they can be reused elsewhere.
• profile_nav method should be more extensible, allowing for third party tabs.
• Allowed actions in user_admin_load and friends should be filterable.
• Should move the bp_members_admin and xprofile_user_admin actions into a method so there are no global scope is_admin() checks.
• Thinking we should namespace all new functions with bp_ even if it does not match the existing conventions in some files.

[imath]

Thanks for your feedback jjj, just before i commit :)

I thought it was best to make a new patch : 5197.03.diff to directly take your feedback in account.

[johnjamesjacoby]

In 7764:

First pass at introducing BuddyPress profile editing to /wp-admin:

• New bp-members-admin.php and accompanying assets to handle the initial admin page creation (outside of XProfile).
• New stats template functions in Blogs, Friends, and Groups components, to provide additional meta data about a members community involvement.
• Modifies some existing XProfile admin/template/filters to make it more accommodating to querying for profile data outside of BuddyPress's traditional displayed_user context.
• Props imath, boonebgorges, johnjamesjacoby. Fixes #5197.

[hnla]

Just checked this out - excellent work @imath, @jjj, @boonebgorges

Looking at the stats panel wondered if it couldn't be elaborated on a little?

I added a stats group of functions to the Status project a while back:
​https://github.com/buddypress-themers/status/blob/master/functions.php

Which added:
status_member_profile_stats_member_status()
status_member_profile_stats_member_topics()
status_member_profile_stats_member_replies()
status_member_profile_stats_new_blog_post()
status_member_profile_stats_member_comments()

[imath]

Replying to hnla:

Just checked this out - excellent work @imath, @jjj, @boonebgorges

Thanks @hnla, interesting idea :)

i've checked your functions, and i wonder if a unique function that would request only once the activity table grouping counts by activity status for the displayed user might be better. This way it would avoid some queries if for instance the forum is not active or the user cannot publish posts.

I agree that such stats about activities can be interested for the community administrator.

[hnla]

if a unique function that would request only once the activity table grouping counts by activity status for the displayed user might be better.

Absolutely, makes sense, just floating the idea out there, as you say people love stats, the more the better, but for admins they can be a useful tool to gauge a users site participation.

[ubernaut]

Also in larger organizations the person in charge of community participation isn't the same person as the admin. MY vote would be to allow the admin/super decide which roles can views the stats similar to the way jetpack does it now.

[imath]

@hnla @ ubernaut

I think, as this ticket was mainly about editing the profile fields in wp-admin and is closed, a new enhancement ticket would be great to keep on talking about statistics in the community profile starting with activity statistics because i really believe it can be a great feature for community administrator.
About other roles, i'd like to have other members team opinion. What's sure is that, thanks to @jjj the different functions can be used anywhere you want in the site.

[johnjamesjacoby]

Our roles and capabilities implementation is quite a ways off at this point; far enough where it's likely not worth thinking about for this feature. Once we go down that road, there are several specific places where it would be used for moderation before something like stats would become a privacy or role concern.

I do agree that, eventually, pretty much everything will need role/cap checks. Until then, I think it's fine how it is.

[needle]

This feature is really nice... thanks for the efforts to implement this! One minor suggestion - it would be great to have a function akin to bp_is_register_page() or bp_is_user_profile() to check if this screen is active. At present, I am checking !is_null( $bp->profile->admin ) ) which works but seems somehow inelegant.

[lenasterg]

Great addition!!!
I'm not sure which will be the required WP version for BP 2.0, so just a minor notice.
The wp_unslash() function will require wp3.6.
This function is used in ​https://buddypress.trac.wordpress.org/browser/trunk/bp-members/bp-members-admin.php#L227

[boonebgorges]

In 7990:

Use stripslashes_deep() rather than wp_unslash() in bp-members-admin.php

The functions do the same thing, but wp_unslash() was not available prior to
WP 3.6.

See #5197

Props lenasterg

[aptrenovationuk]

Replying to johnjamesjacoby:

Replying to imath:

I'll first restart from jjj's version of the patch and do the split between bp-members and bp-xprofile. i'll upload a new patch asap. Removing the commit keyword till that new patch.

Perfect. Looking forward to getting this into trunk asap.

TBH I'm very comfortable committing this into trunk now and running it out to cycle 2.0,
I like Imath's take on it with the caps,rolls etc...getting an early start on this feature, as it's likely to change quite alot.

​Professional Architectural Builders