Display and filter by member type on Dashboard > Users

[boonebgorges]

Now that we support member types #6006, and are providing admin UI for viewing/setting that member type on an individual basis, we should consider the following enhancements to Dashboard > Users:

• a Member Type (sortable?) column
• the ability to filter by Member Type. This could be akin to the current Role links, or perhaps a dropdown (in case there are tons of types)

[imath]

I agree, this will be really great.

[espellcaste]

+1

[DJPaul]

I would suggest these extra columns only show up if 1) there is a member type registered or, 2) hidden by default but with a toggle to show them under the "screen options" panel. Otherwise this becomes clutter for people who aren't using the feature.

[slaFFik]

Users => Manage Signups should have this column as well, as user might select a type while registering.

IMO, we should have 2 dropdowns on Users page:

1) Change member type to... (same as for roles, with a Change button)
2) All member types (with a list of all types and a Filter button)

[mercime]

Related:
#7182 UI for All Member Types in wp-admin
#7181 UI to Add New Member Type in wp-admin

[slaFFik]

I decided to not add a Filter by member type dropdown. Reason - it takes to many space, imagine bbPress activated as well (ordinary scenario):
Change role, Change forum role, Change member type, Filter by member type.
Those dropdowns just don't fit the screen. So I made the type for each user as a link to filter all users.

Column can be made hidden in Screen options.

Dropdown and column are displayed only if any member types are registered.

[slaFFik]

Some whitespace fixes

[dcavins]

Hi @slaFFik, this is really good. I've tested your new patch this morning and have a few comments:

• The function users_type_change_to() relies on a passed parameter $which to know whether the control is above or below the table. This parameter wasn't passed to the action hook until WP 4.6, so in 4.5 and earlier, the upper dropdown's input never works (it has the same name as the lower, so it's overwritten in the $_REQUEST). Is there anything we can do to make this work in 4.5 and earlier? Short of a global variable, I'm not sure how to output the control only once in earlier versions.
• The "Change" button uses a duplicated id. This is the behavior of the "Change Role" control, too, but I'd still like to avoid it.
• I like the way you've handled filtering by type (using the type column output as filter links). This is a nice, unobtrusive touch.
• It would be cool if the Member Type column were sortable, but that could be a future improvement.

Updates I've made in the patch I'll add:

• Use the $id_name variable in the label in users_type_change_to()
• Change the foreach behavior so that all member changes are made before redirecting in users_type_bulk_change().

Thanks for the cool stuff!

[dcavins]

A few small changes.

[dcavins]

I've gone through this patch again, switching the calls to buddypress()->types to use the member types fetching functions. I also changed some function names to be more descriptive and filled out the descriptions a bit more. There are two @TODOs marked that I'd especially like feedback on.

• What's the best way to find all the users of a particular type? The code currently uses get_objects_in_term() but maybe doing a BP_User_Query would be better?
• The general WP function translate_user_role() is used on the member type name at output, but I'm not sure it will have an effect.

My note from above is still an open question:

The function users_type_change_to() relies on a passed parameter $which to know whether the control is above or below the table. This parameter wasn't passed to the action hook until WP 4.6, so in 4.5 and earlier, the upper dropdown's input never works (it has the same name as the lower, so it's overwritten in the $_REQUEST). Is there anything we can do to make this work in 4.5 and earlier? Short of a global variable, I'm not sure how to output the control only once in earlier versions.

Thanks for your feedback!

[dcavins]

Another round of updates.

[dcavins]

Add a "No Member Type" option to dropdown to remove types.

[boonebgorges]

What's the best way to find all the users of a particular type? The code currently uses get_objects_in_term() but maybe doing a BP_User_Query would be better?

A BP_User_Query will require more resources, and will also require some work to avoid recursion (since a BP_User_Query eventually calls 'pre_get_users'). If BP_User_Query had enough caching that we could avoid hitting the database, I'd say we should switch to it. Since that's not currently the case, get_objects_in_term() seems like a simpler approach.

The general WP function translate_user_role() is used on the member type name at output, but I'm not sure it will have an effect.

It definitely won't do anything in this context, since translate_user_role() assumes the default domain, not buddypress. BP member types work differently from WP roles since they're fully defined in code, so I'd say we can leave this out for now. If it turns out that parts are untranslatable after 2.7, we'll look at what hoops we need to jump through to fix it.

The function users_type_change_to() relies on a passed parameter $which to know whether the control is above or below the table. This parameter wasn't passed to the action hook until WP 4.6, so in 4.5 and earlier, the upper dropdown's input never works (it has the same name as the lower, so it's overwritten in the $_REQUEST). Is there anything we can do to make this work in 4.5 and earlier? Short of a global variable, I'm not sure how to output the control only once in earlier versions.

Meh, I wouldn't go to too much trouble to make this work in earlier versions. Only displaying it once (at the top) seems like it'd be fine in this case. Something like:

public function users_table_output_type_change_select( $which ) { 
    static $displayed;

    if ( version_compare( bp_get_major_wp_version(), '4.5', '<' ) && ! empty( $displayed ) ) {
        return;
    }

    $displayed = true;
    
    ...

[dcavins]

In 11110:

Member Types: Use helper function for taxonomy name.

Allows the member type taxonomy name to be filtered.

Props slaFFik, dcavins.

See #6060.

[dcavins]

In 11111:

WP Users List: Add member type bulk change controls and filters.

Add a dropdown select to change the member type of many members in
bulk. Also add a new column, “Member Type,” showing the member’s
assigned member type as a link that leads to a filtered view of the WP
Users table, much like a tag link on the posts table works.

Props slaFFik, dcavins.

Fixes #6060.

[DJPaul]

Per @offereins feedback on Slack, I too think we need to look at this to handle multisite and different root blog configs.

[dcavins]

In 11120:

Use multi-site taxonomy functions on WP User list table.

In WP Users list table, when filtering users by member type, use the
new multi-site-safe taxonomy functions.

Props offereins.

See #6060.

[dcavins]

In 11140:

WP Users List: Refinements to member type bulk change controls and filters.

Apply code improvements from related work on group type (#7175).

• Improve error message presentation.
• Escape strings before output.
• Use strict comparison operators.

Props dcavins, djpaul.

See #6060

[dcavins]

In 11141:

Correct misuse of escaping functions.

Don’t use esc_html_e() when you mean echo esc_html().

Anti-props dcavins.

See #6060, #7175.