[buddypress-trac] [BuddyPress Trac] #4017: Group taxonomy
noreply at wordpress.org
Sat Sep 27 13:53:15 UTC 2014
#4017: Group taxonomy
Reporter: boonebgorges | Owner: boonebgorges
Type: enhancement | Status: new
Priority: normal | Milestone: Future Release
Component: Groups | Version:
Severity: major | Resolution:
Keywords: has-patch |
Comment (by boonebgorges):
Replying to [comment:20 DJPaul]:
> I am refreshing myself about this ticket, and we need to have some
suggestions of how a taxonomy for groups could be used; both by core, and
for other ideas that may be built by a third-party plugin/custom site.
There is a whole bunch of technical discussion on this thread but not too
much about what it would actually be used for (it's been quite a while
since I built a BP site from scratch for someone).
Sure. From the core point of view, the primary way of exposing the content
would be by (a) showing the tags on individual group pages (like you see
on WP posts), which would be links to (b) a directory that is filtered by
matching groups. This would be used for folksonomical organization of
groups. Say, for instance, on http://commons.gc.cuny.edu/groups: we have
groups that are committees vs courses vs clubs; Queens College vs Brooklyn
College vs College of Staten Island; groups about WordPress and poetry and
games in learning. Allowing groups to self-organize using tags is an
enormous win for fostering discoverability and connections between like-
The real power would be in third-party plugins. For almost every BP
project I've worked on, I've built some custom version of "group types".
Take http://openlab.citytech.cuny.edu. Courses, Projects, Clubs, and
Portfolios are all groups (click through to a URL to see). They're
differentiated based on a piece of groupmeta, and then we do a custom
filter in eg http://openlab.citytech.cuny.edu/courses/. Then, we use this
group data to display different functionality for different groups - note
the different navigation between Portfolio and Course groups, for example.
Groupmeta works for this purpose, but is cumbersome, and ultimately fairly
slow. Using taxonomy would make it much more scalable, and it would allow
for multi-directional querying much more easily: show me the type this
group belongs to, show me all the groups belonging to this type.
To reemphasize: a group taxonomy API is something I would use on nearly
every BP client site. I do think that, in core, we would probably want to
be modest in the way we expose the UI (at least at first). But the
underlying infrastructure would be hugely valuable.
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4017#comment:21>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac