Skip to:
Content

Opened 19 months ago

Last modified 17 months ago

#7181 new enhancement

UI to Add New Member Type in wp-admin

Reported by: mercime Owned by:
Milestone: Awaiting Contributions Priority: strategic
Severity: normal Version:
Component: Members Keywords: needs-patch
Cc: brajesh@…

Description

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.

Attachments (1)

member-type-add-new.png (100.3 KB) - added by mercime 18 months ago.
Example

Download all attachments as: .zip

Change History (14)

#1 @DJPaul
19 months ago

  • Priority changed from normal to strategic

@mercime
18 months ago

Example

#2 @mercime
18 months ago

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

#3 @boonebgorges
18 months ago

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:

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.

#4 @mercime
18 months ago

Thanks @boonebgorges :D

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

#5 @tw2113
18 months ago

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

#6 @sbrajesh
18 months ago

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?

#7 @sbrajesh
18 months ago

  • Cc brajesh@… added

#8 @r-a-y
18 months ago

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.

Last edited 18 months ago by r-a-y (previous) (diff)

This ticket was mentioned in Slack in #buddypress by mercime. View the logs.


18 months ago

#10 @boonebgorges
18 months ago

  • Keywords needs-patch added

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?

#11 @tw2113
18 months ago

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.

This ticket was mentioned in Slack in #buddypress by boone. View the logs.


17 months ago

Note: See TracTickets for help on using tickets.