UI to Add New Member Type in wp-admin

[mercime]

Better late than never, this screen will make it easier for Site Admins/Builders to create any number of Member Types in the admin area.

[mercime]

Example

[mercime]

Attached is a screenshot of the Add New Member Type screen generated from the BP Member Type Generator plugin by @sbrajesh.

[boonebgorges]

Thanks for posting this screenshot, @mercime!

This ticket should be tackled alongside #7179.

I would love to get input on this ticket from two people:

• @sbrajesh, since he has built a plugin that does exactly this
• @tw2113, since he is maintainer of the popular ​https://wordpress.org/plugins/custom-post-type-ui/

I would imagine that each of these fellows has some ideas about which UI conventions work and which don't; which features it makes sense to expose to users and which it does not; ways of storing the data that are forward compatible with potential changes to the API; etc.

[mercime]

Thanks @boonebgorges :D

Related:
#7182 UI for All Member Types in wp-admin
#6060 Display and filter by member type on Dashboard > Users

[tw2113]

I can do my best, but I don't know how "professional" my feedback will be. CPTUI has mostly been self-rolled and not using the Settings API, for example. We do mimic it with the generated markup to best match WP admin UI as best we can, and are looking to move the sections to the metabox-style dropdown that a lot of WP uses.

I've never gotten a ton of feedback from users other than "you made me click a lot more" back 1.5 years ago. Keep clicking to a minimum where possible :D

[sbrajesh]

Thank you @mercime and @boonebgorges
I will share what I heard from the community. If we are going to implement the member type UI in the admin, the first thing people will want is member type as core profile field. We should have single/multiple member type as profile field(an other ticket?) and we need some way to synchronize these.

Since BuddyPress already restricts fields based on the member type, adding the field type and UI will make it complete.

Also, If we are adding it to core, we need to think about the different ways member types can be created. How do we handle a member type registered via code?

My implementation uses post type but I believe It will better to do it directly on terms screen. After all, Member types are terms and WordPress support custom meta now( Thank you @boonebgorges ). Using terms screen will save us all the overheads and makes more sense to me. What do you think?

[r-a-y]

After all, Member types are terms and WordPress support custom meta now

As of WordPress 4.4, WordPress does support custom meta, but for BP 2.6, we support a minimum of WP 4.1.

We could make this a WP 4.4+ feature only.

[boonebgorges]

Thanks for the feedback, @sbrajesh and @tw2113 ! It's very useful to have the benefit of your experience.

the first thing people will want is member type as core profile field. We should have single/multiple member type as profile field(an other ticket?) and we need some way to synchronize these.

I assume that this means two things: (1) An easy way to display the current user's member type within the context of the profile, and (2) a way for users to edit their own member type in the profile interface. Is that right? I agree that this would be useful, but it's definitely a discussion for another ticket.

Also, If we are adding it to core, we need to think about the different ways member types can be created. How do we handle a member type registered via code?

Yeah, we'll have to make decisions about this. Looking at the code for bp-member-type-generator, it looks like that plugin doesn't do any checks at all. If a plugin manages to register its types before bp-member-type-generator loads its types from the database, it wins; otherwise, the ones in the DB win. (And since the convention is to register at 'bp_register_member_types', there are likely to be race conditions, oddities in multisite config, etc.) @tw2113 - What does CPTUI do to resolve/prevent these conflicts?

I think we'll be best off registering types from the DB as long as possible, giving precedence (as much as we can) to types that are registered in code. It's relatively easy to throw a notice in the UI that informs someone that their new Type conflicts with an existing one, and easy to tell them how to fix it (ie, change the slug); it's hard to do these things when the "loser" is the one that's hardcoded in a plugin.

My implementation uses post type but I believe It will better to do it directly on terms screen. After all, Member types are terms and WordPress support custom meta now( Thank you @boonebgorges ). Using terms screen will save us all the overheads and makes more sense to me. What do you think?

Two things. First, as noted, term meta requires WP 4.4. Second, the current implementation of member types uses taxonomy terms to store relationships, but handles the registration of member types in code. When you register a member type 'student', the 'student' term doesn't exist in wp_terms or wp_term_taxonomy until at least one user has been given the type 'student'. In other words, the terms tables are not a "source of truth" for anything; it's only a byproduct of the fact that we're using wp_term_relationships for storage that anything is put into the term tables at all. This approach would need to be rewritten in order to leverage termmeta (and the term Edit panel, though the question of which admin UI to use is pretty independent of the storage mechanism).

I'm willing to be proven wrong about this, but my feeling is that the Member Type feature will be easier to maintain in the long run if we continue to use a global registry for member types, with the database used only for relationship storage. This suggests that a CPT is the right choice. (I see that CPTUI stores everything in an option, which seems like it'll make everything really hard, so I think we should avoid it.)

I also like the idea of using as much of WP's post.php interface as possible, and storing as CPTs will help with that.

Anyone want to have a first go at a patch, based on the points outlined above?

[tw2113]

Pre CPTUI 1.0.0 had an indexed array that did provide conditions for race conditions. I recall a small handful of people who would have multiple tabs open editing multiple post types/taxonomies and the index would cause issue. With 1.0.0 I moved all of the legacy settings to a named array, using the slugs for index values, allowing for general prevention of issue. Chances are high that people aren't editing the same post type/taxonomy in multiple tabs.

[boonebgorges]

See ​https://github.com/buddypress/bp-types-ui

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/

[imath]

Hi!

As discussed during our latest dev-chat (July 29, 2020), ​7181.patch is based on the code of this ​PR that was merged into the ​BP Types UI GH repository we've been using to test different BuddyPress Types Admin UI scenarii.

Don't hesitate to read ​PR description for detailed information. In short, now our WordPress required version is the same than the one that introduced the WP Term Meta feature (4.9), we believe we can adapt the WP Term UI to match our BP Types needs.

The patch is taking in charge Admin UI for Member Types and Group Types (see #7179), and I've improved a bit what has been done into the ​BP Types UI plugin to potentially take in charge any other possible/future Types (Friends, Activity...).

Here's a screenshot of the BP Member Types Admin UI:

Let's try to have this in for 7.0.0.

[imath]

In 12727:

BP Types: improve the BP Core Taxonomy API

• Introduces the bp_insert_term() function to save a BP Type into the database.
• Introduces the bp_get_terms() function to retrieve BP Types from the database.
• Introduces the bp_delete_term() function to remove a BP Type from the database.

Props mercime, DJPaul, dcavins, boonebgorges, tw2113, sbrajesh

See #7179
See #7181

[imath]

In 12728:

BP Types: introduce type metadata registration & add a Member type one

• Introduces the bp_register_type_meta() function to register metadata for the Type taxonomies.
• Introduces the bp_get_type_metadata_schema() to get common to all types metadata properties.
• Adds the bp_register_type_metadata hook. Hook to it to register the Member type metadata.
• Introduces the bp_get_default_taxonomies() to list the BuddyPress default taxonomies (BP Email & Member Type taxonomies).
• Improves bp_register_default_taxonomies() so that it use the previous point new function.
• Adds labels and arguments to the Member Type taxonomy.
• Introduces the bp_get_taxonomy_common_args() to retrieve common BP Taxonomy arguments.
• Introduces the bp_get_email_tax_type_args() & bp_get_member_type_tax_args() so that the BP Email & the Member type taxonomies use it to retrieve its arguments enjoying the previous point new function.

Props mercime, DJPaul, dcavins, boonebgorges, tw2113, sbrajesh

See #7179
See #7181

[imath]

In 12729:

BP Types: merge BP Types saved in DB with the ones registered by code

• Introduces the bp_get_taxonomy_types() to merge types saved into the database with the types registered by code. It's now possible to edit all properties of the registered by code types except for the type's slug which needs to be unique.
• Caches these merged types.
• Introduces the bp_get_member_types_registered_by_code() to only get member types registered by code.
• Updates the test_bp_get_member_type_should_not_return_unregistered_types() unit test to test_bp_get_registered_by_code_member_type_should_not_return_unregistered_types() to check the previous point new function.
• Introduces the bp_update_type_metadata() function to update a type's metadata.

Props mercime, DJPaul, dcavins, boonebgorges, tw2113, sbrajesh

See #7179
See #7181

[imath]

In 12730:

BP Types: make it possible to manage BP Types from the WP Admin

• Introduces functions to handle BP Types insertion, modification and deletion.
• Introduces a new JavaScript file to customize the default WP Terms Administration screens.
• Introduces the BP_Admin_Types class to make it possible to manage any BP Types.
• Adds the Member type's Administration screens.

Props mercime, DJPaul, dcavins, boonebgorges, tw2113, sbrajesh

See #7179
Fixes #7181

[johnjamesjacoby]

In 12775:

Group/Member Types: Capitalize "types" in submenu page & titles.

This commit ensures that title case is employed in areas of the WordPress admin UI where it is expected to be.

See #7179, #7181.

[johnjamesjacoby]

In 12776:

Group/Member Types: More string changes.

This commit includes the following code changes:

• Change case of strings to match how WordPress core labels are cased
• Reorder schema so singular is before plural (see: order of adjectives)
• Adds missing taxonomy labels for core functionalities that could be activated or used later (hierarchy, popularity, etc...)
• Simplifies all verbiage, to be more concise without sacrificing accuracy or descriptiveness (removes example URLs, encoded quotes, etc...)
• Remove "member" references from default strings, and re-add them back in using member-specific variants to match how groups works
• Related inline documentation

Together, these changes bring both Group and Member types closer in readability and usability to other taxonomies, making them feel a little bit more familiar, while also keeping strings within 2 lines tall on most viewport sizes, and hopefully making them easier to understand for users who are new to these features.

See #7179, #7181.