[buddypress-trac] [BuddyPress Trac] #7181: UI to Add New Member Type in wp-admin
noreply at wordpress.org
Fri Jul 29 18:19:50 UTC 2016
#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
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
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
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7181#comment:10>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac