Skip to:

Opened 4 years ago

Last modified 20 months ago

#3961 new enhancement

Hierarchical groups

Reported by: sooskriszta Owned by:
Milestone: Future Release Priority: normal
Severity: major Version:
Component: Component - Groups Keywords: dev-feedback 2nd-opinion
Cc: sooskriszta, ddean, ubernaut@…


Hierarchical groups functionality should be part of the core, complete with member propagation – giving 3 options to admin … upwards propagation, downwards propagation, no propagation…

Not having hierarchical groups in BuddyPress core is like if hierarchical pages were not part of WordPress core…

Attachments (1) (90.6 KB) - added by abweb 4 weeks ago.
Archive contains patch file and required files

Download all attachments as: .zip

Change History (20)

#1 @boonebgorges
4 years ago

  • Cc ddean added
  • Keywords dev-feedback 2nd-opinion added
  • Milestone changed from Awaiting Review to Future Release

Not having hierarchical groups in BuddyPress core is like if hierarchical pages were not part of WordPress core…

That's a bit extreme. Hierarchical groups would be useful for some implementations of BuddyPress, but it's not obvious that it's overwhelmingly required for most instances.

From the data schema point of view, hierarchical easy - just allow for a parent_id or something like that. But there are a ton of questions to be asked about what this means for users. Member propagation is one question, as you've addressed above. But what else would the parent-child relationship mean for groups? Would aspects of the groups be merged (forums, activity, etc)? Would each group have a display of its child and parent groups, perhaps in the header? Would this require additional filters on group directories, or possible tree-like views of group directories?

Again, the technical issues here are (mostly) not that difficult. But it's only worth adding the feature(s) if it can be done in a way that is clear to all users, and that proves useful to most.

In any case, I have a couple of alternate suggestions to bundling all of this with BP:

1) Build proper group taxonomy and meta support. If BP had built-in support for group categories and/or tags, it would solve a big part of the impetus behind group hierarchy (that is, explaining that certain groups are related to each other). IMO, group taxonomy is of much broader appeal than standalone hierarchy, and it's clearer (to me at least) how it would be implemented from a UX point of view. If this were done, then it would be pretty easy to build a plugin that does the additional work of, eg, propagating group membership among similarly categorized groups.

2) Build better support for ddean's BP Group Hierarchy plugin into BP core (ddean - I added you as a CC to this ticket - hope that's not too rude :) ). This plugin is popular and highly regarded, but I think that David has run into a couple of problems with implementation that have led to some less-than-ideal situations. For one, his plugin has to modify BP's groups table to add a parent_id column; we might consider doing this in BP itself. He's also built his own version of bp_has_groups() just so that he can add hierarchy support, and he does some clever tricks to mess with BP_Groups_Template. If we add a parent_id column to our db schema, we could also add hierarchy support (parent_id, and maybe others if it's relevant) to the bp_has_groups() stack of functions. Then we let the plugin provide all the necessary UI elements, like it already does.

In the short term, I lean toward the latter. It's something we can do fairly easily, it'll make ddean's life much easier, and it won't affect BP users who aren't interested in group hierarchy. Long term, we could then talk as a team about how/whether to implement some of the user-facing stuff in BP in future versions.

#2 @DJPaul
4 years ago

I think adding a database column and modifying groups' query stack for something we aren't going to expose directly in core is not the right approach. If we came to the decision that this is something we wanted to do in core, we can certainly build these parts in, even if the release doesn't allow us enough time to build a UI for it (leaving it to the plugin).

#3 @ddean
4 years ago

Hi, all! Sorry for being tardy; I didn't have an email address set in my Trac profile, so I didn't get the cc.

I thought the long term plan was to make groups into a custom post type, with the built-in taxonomy support that provides, so I've been happy to keep patching things in until then. Is that still the ultimate goal?

While I appreciate anything that makes my life easier :), most of the integration work has already been done and, for compatibility's sake, couldn't just be taken out. Whatever you all decide to do is fine, and I'd be happy to provide a short list of changes that could improve extensibility.

This seems to be the key:

Again, the technical issues here are (mostly) not that difficult. But it's only worth adding the feature(s) if it can be done in a way that is clear to all users, and that proves useful to most.

If download counts are to be believed, hierarchical group users account for ~1% of BuddyPress users, and I've received only a handful of requests for membership propagation. And, though I can certainly see the value of this feature, the time needed to build and test a UI that makes it flexible enough to be useful without becoming a management or security issue has been enough to keep me away from it so far.

#4 @sooskriszta
4 years ago

Innovator's dilemma. Should we go after current audience or a bigger market out there?

Does use of hierarchical groups by 1% of BuddyPress users mean it is not a much-needed function or does it mean that the plugin doesn't do what users want it to do? (no offense ddean..i don't mean it doesn't do what it's intended to do...subtle difference)

I remember the days when WordPress was simply a *blogging* platform and didn't have hierarchical pages. Look at it now - since this became a core feature, a good proportion of people use WP as their CMS, including yours truly.

I truly believe that hierarchical groups with upwards/downwards propagation will open BuddyPress up for users and uses that are beyond its reach at the moment...

Last edited 4 years ago by sooskriszta (previous) (diff)

#5 @boonebgorges
4 years ago

I thought the long term plan was to make groups into a custom post type, with the built-in taxonomy support that provides, so I've been happy to keep patching things in until then. Is that still the ultimate goal?

Maybe. We have to clear some conceptual hurdles first, related to scaling and schema. IMO, the two easiest components to map onto CPTs are Messages and Groups (though not group members). I may write a proof-of-concept after 1.6 comes out, but it will be a while before those decisions become final.

Regardless of the CPT situation, I think that we should move forward with proper meta/tax for groups. On that note, see

#6 @sooskriszta
4 years ago

  • Version changed from 1.5.3 to 1.5.5

#7 @boonebgorges
4 years ago

  • Version 1.5.5 deleted

#8 @sooskriszta
4 years ago

I don’t suppose a ton of people currently use hierarchical groups in BuddyPress. But I am certain that features like this will go a long way in opening up new markets for the script, way beyond just small techie groups.

It’s a usability thing. Let me take an example:

Site for networking of dentists in the UK.
What I have in mind is at top level 4 groups:

  • England
  • Wales
  • Scotland
  • Ireland

Then within each group, there are subgroups for counties.

Within each county subgroup, there are sub-subgroups for town/city etc.

Within the county sub-subgroup for town/city for particularly large cities, there could be sub-sub-subgroups for boroughs.

If Paul joins the group for Exeter, he should automatically become a member of Devon and England respectively.

I’m sure there might possibly be other ways of doing this (e.g. adding categories or tags); I just don’t see anything so instinctive or natural.

There can be multiple other examples.
For a medical professionals organization:
Doctor > Neurology > Clinical neurophysiology
For a university:
Business School > MBA > Managerial Accounting

#9 @sooskriszta
3 years ago

24000 downloads of @ddean's Group Hierarchy plugin which is about 1.6% of total BuddyPress downloads. Consider also that BuddyPress has been out since April 30, 2009 while the plugin was first released in February 2011 and the actual proportion of the plugin users is likely to be much higher perhaps as high as 3-4%.

Further, 100% of the active installations of BP Group Hierarchy are of the latest version, meaning that these folks are likely using the latest version of BuddyPress too. If that's the case, and if we can use downloads as a proxy for active installations (and it may not be):
BP Group Hierarchy 1.3.8 active installs ~ 25,000
BuddyPress 1.7+ active installs = 1,562,730 x 32.6% ~ 500,000
BP Group Hierarchy 1.3.8 active installs as a proportion of BuddyPress 1.7+ active installs = 5%

This is still a small minority and I'd be the first to admit that for quite a while hierarchical group use will remain a minority activity, though it will probably be a bigger minority.

What I do posit is that

  1. it is not an insignificant minority.
  2. the function will help grow the pie.

#10 @sooskriszta
2 years ago

2.0? :-)

#11 @vernonfowler
2 years ago

30,510 downloads of BP Group Hierarchy to date 31/3/2014
591 downloads of BP Group Hierarchy Propagate -
I love both these plugins.

As much as some of our communities depend on these plugins layered on top of BuddyPress, I can't see Group Hierarchy making it into core for as long as it has less than 50% of the number of BuddyPress installs.

I'd rather find ways to further optimise BuddyPress itself (and bbPress for that matter). Right now P3 (Plugin Performance Profiler) reports 24% (0.3533 secs) and 12% (0.1749 secs) of my load times are dedicated to these 2 plugins respectively - the 2 heaviest plugins I have (shortly followed by Adminimize at 11%).

This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.

2 years ago

#13 @ubernaut
2 years ago

  • Cc ubernaut@… added

#14 @sooskriszta
23 months ago

One big unresolved issue is propagation:

If Group 1 is a parent, and Groups 2 and 3 are children of Group 1, then should someone joining Group 2 automatically become a member of Group 1? Or should someone joining Group 1 automatically become a member of Group 2?

Theoretically, both approaches seem quite valid. However, let's look at live cases and why folks want hierarchical groups. The parent-child relationship essentially a bit like successive filters applied to the groups. At the top level (say Group 1), there's everyone. Then we filter down by interest/ specialization/ location/ class/ what have you. So in Group 2 we have fewer folks - only those that are into Group 2 stuff. Then we have Group 4 - a child of Group 2. It has even fewer folks. Super specialists.

In other words, in live situations, it seems that the dominant use case is one where someone (say A) joining a child should automatically be added to the parent. (of course, there needs to be a check so that if A is already a member of 1, then that doesn't throw an error when A joins 2).

Also, there would be some communities that would not want propagation and would want parents and children to operate independently. Thus, propagation should be a checkbox option.

What of activity streams? Same upwards propagation principle applies. As anyone who has used a CRM software can attest, if I post something in the activity stream of a contact person then that propagates up to the activity stream of the contact person's organization's activity stream.

#15 @sooskriszta
23 months ago

So, for instance:
University A uses BuddyPress for its Intranet.
Top level group is Professors.
2nd level groups are Schools: Graduate, Law, Business and Medicine.
Subgroups are departments, e.g. at Business School: Accounting, Finance, Marketing, Operations and Organizational Behavior.

The University would want everyone joining Finance group to also be a part of the Business School group and Professors group.

It may switch activity propagation off or on. If it turns activity propagation on then the discussions at Finance group percolate all the way up to the Professors group. If activity propagation is off then they don't.

But if there is an announcement that it needs everyone to read, the university only wants to post it once on Professors group and wants everyone to read. Well, hey, there is no need for the downwards propagation of activity stream - all professors are already propagated up and can read the announcements posted in the Professors group!

#16 @sooskriszta
23 months ago

  • Summary changed from Need hierarchical groups to Hierarchical groups

#17 @sooskriszta
23 months ago

  • Component changed from Core to Groups

#18 @sooskriszta
20 months ago

Would #4017 bring us closer to hierarchical groups?

#19 @boonebgorges
20 months ago

Would #4017 bring us closer to hierarchical groups?

Not strictly speaking, though you could definitely use group taxonomies to fake the parent/child relationship. (A truly general solution would be for WP to adopt a relationships API. See

4 weeks ago

Archive contains patch file and required files

Note: See TracTickets for help on using tickets.