[buddypress-trac] [BuddyPress Trac] #7181: UI to Add New Member Type in wp-admin

[buddypress-trac]

#7181: UI to Add New Member Type in wp-admin
-------------------------+-----------------------------
 Reporter:  mercime      |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  strategic    |   Milestone:  Future Release
Component:  Members      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |
-------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:   => needs-patch


Comment:

 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?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7181#comment:10>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac