Opened 13 years ago
Last modified 10 days ago
#4017 new enhancement
Group taxonomy
Reported by: | boonebgorges | Owned by: | boonebgorges |
---|---|---|---|
Milestone: | Awaiting Contributions | Priority: | normal |
Severity: | major | Version: | |
Component: | Groups | Keywords: | needs-patch |
Cc: | vpundir@…, slava.abakumov@…, vivek@…, mercijavier@…, nick@…, pixcherie@…, smsjun@…, kraft@… |
Description
WP taxonomy is adaptable for any type of content, even content that is not stored in WP's native tables. Groups are an obvious use case for this - groups currently have no semantically useful metadata save for their names and descriptions, and in nearly every BP installation I've ever done, this lack of taxonomy has been sorely missing.
I've got an idea of how this might be done, at least on the back-end. I will work up a proof-of-concept and solicit feedback on the UI.
Attachments (6)
Change History (50)
#2
@
12 years ago
How goes it on this front Boone?
I imagine you have been and are busy with 1.6 and 1.7, but one can still hope :-P
#3
@
12 years ago
- Cc vpundir@… added
Great idea, after all, taxonomy and group are synonyms ;-)
There are 2 key aspects to consider
- Most folks use WordPress because it's easy-to-use (as opposed to say Drupal). By definition, the target universe of BuddyPress is predominantly less tech-oriented/savvy, more ease-of-use focused.
- BP core developers are always exasperated, out-of-breath and overworked, because there are very few of them, and community patches to core are few and far-between. Compare this to WordPress, which owing to a massive overall universe has many more contributing developers who know how WordPress (and CPTs) work.
I understand that the challenges are great
- The change in architecture is probably massive, just shy of the changeover from bbPress standalone to bbPress plugin
- The worst part of it all would be migration of current installations to the custom taxonomy-based system
That being said, there are great advantages which make the effort totally worth it (easy for me to say since I don't have to do it..heck, I don't even know how much effort is needed):
- Stable, tried, tested system
- Lots of functionality comes baked in, freeing up developers
- User-friendly interface comes already baked in making UI hardwork e.g. http://wordpress.org/extend/plugins/bp-group-organizer/screenshots/ a thing of the past, and making BuddyPress more appealing to target universe.
- "Unexpected" benefit - hierarchical groups #3961
- More developers can participate as they have to learn fewer BuddyPress-specific things...
- Almost certainly more WordPress plugins would become BuddyPress compatible
#4
@
12 years ago
sooskriszta -
Thanks for your thoughts on this issue. I disagree with a number of your points, though.
User-friendly interface comes already baked in making UI hardwork
It's not going to be at all feasible to use WP's CPT UIs out of the box. These UIs are designed for text-based content types (with fields like Author and Last Updated), which doesn't match BP content types at all. If we decided to use WP's core UIs for these content types, we would have to do extensive modifications to make it usable for BP content. It's more likely that we would build a totally separate UI that is designed to look like WP's, which is in fact what we've already done with Activity in BP 1.6 and Groups in 1.7.
More developers can participate as they have to learn fewer BuddyPress-specific things...
As noted in the linked thread, this is highly speculative and probably not true. Refactoring BP to use CPTs would require a large middleware, which would translate functions like the existing bp_has_groups()
to use CPTs or taxonomies under the hood. This middleware would be pretty extensive, and in many cases very unintuitive, such that at the surface level, there would be very little resemblance to CPT or taxonomy architecture at all. In practice, it's unlikely that any developer of BP plugins/sites/themes would ever actually use the CPT functions directly, because there would be so much convoluted parameter translation going on; instead, they would use our top-level API functions like bp_has_groups()
. But we already have bp_has_groups()
.
Almost certainly more WordPress plugins would become BuddyPress compatible
This is the case for some plugins that manage data storage at a low level (such as persistent caching plugins). It's very unlikely to be true at a higher level, because (as described above) BP's implementation of CPTs/taxonomies would be so vastly different from the typical use case.
The real argument against using CPTs for BP is that it wouldn't work at scale. Take Groups as an example: In order to map the current Groups data schema onto a CPT (or onto a taxonomy, which would actually be even harder), we would end up using some custom taxonomies, a variety of postmeta, and possibly some direct filters on WP's database calls. When you start scaling to, say, hundreds of thousands of groups, and when you then start using WP_Query
to filter by numerous taxonomies and postmeta values, you have a situation where performance degrades exponentially, because of the underlying nature of WP's CPT architecture.
The bottom line is that CPTs are designed for developers who have mostly text-based content, and want a quick, safe, and easy way to implement that content in WP. CPTs are emphatically *not* an all-purpose data storage solution, especially at scale. (Core developers I've spoken to on this point are in full agreement.)
If anyone has the time, inclination, and ability to develop a proof-of-concept CPT port of any of BP's components, I would be delighted to do some benchmarking to confirm or reject some of the arguments that have been made against BP-CPT.
#6
@
11 years ago
Would love to see this come to fruition.. We are trying to manage 1000+ groups and it is getting tedious to say the least...
Cheers
#8
@
10 years ago
Hi boonebgorges just found this ticket, i had to quickly build something this week end for my job using a WP Taxonomy to add tags to Groups. So i've built it as a plugin as i wasn't sure it was a potential feature for core.
Just published it on my github, you can have a look / test it : https://github.com/imath/bp-groups-taxo
i'm explaining why i've built it on my blog (french) http://imathi.eu/2014/06/02/bp-groups-taxo/
If you/team think it can be an interesting feature, i can try to build a patch.
On a side note, i think this ticket is relative #1706
This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.
10 years ago
#11
follow-up:
↓ 12
@
10 years ago
This approach reminds me of what Justin Tadlock did with users and taxonomies:
http://justintadlock.com/archives/2011/10/20/custom-user-taxonomies-in-wordpress
Of course, users are not a post type, but Justin used a fake post type to use the existing taxonomy API.
I followed a similar approach with activity hashtags. However, do we like faking a post type in order to take advantage of the taxonomy API?
#12
in reply to:
↑ 11
@
10 years ago
Replying to r-a-y:
However, do we like faking a post type in order to take advantage of the taxonomy API?
Thanks a lot for your feedback r-a-y, i understand your concern. When i was building the plugin i've had the same. The fact that the "link" object is doing so in WordPress core motivated me to keep on building it. The great concern i had was: does using this method can have an impact on regular post types ? For instance if the term is 'news' for a post and a group, does deleting the group taxonomy would delete the post type one ? Or would the count be messed up if group id == post type id for the same term ?
So i've search tickets in WP Core trac to see if this kind of impacts was existing between "link" and posts or pages and couldn't find one.
The tests i've made with group tags (i agree it should be "stressed" more), did not have any impact either. I think i'd trust WP Core, if this use was a danger, then it could be easy to do some get_post_type( $object_id ) in functions of wp-includes/taxonomy.php and bail if it's not a real post type..
Finally, in a way, we are already faking post types in BP Theme Compat ;)
for instance the post type 'bp_group' argument in bp_theme_compat_reset_post
function of BP_Groups_Theme_Compat->directory_dummy_post()
#13
@
10 years ago
- Keywords has-patch added
Building 4017.patch, i've realized, on a multisite config, there's no edit-tags.php (etc..) in the network admin. So it took me a while to "rebuild" the admin UI.
To edit tags, i use an adaptated version of WordPress built in tag meta box in all group screens (admin/edit/create).
I think it works fine, but i've found this annoying behavior in taxonomies. I am a bit disappointed to have found it once i ended the patch :(
Here are some screenshots :
- Groups directory : https://flic.kr/p/nT5dPw
- Group Admin Screen : https://flic.kr/p/nV2vZW
- Group Edit Screen : https://flic.kr/p/nCBZfg
- Group Tags Admin : https://flic.kr/p/nV7vPX
I haven't tested the patch on non multisite configs.
This ticket was mentioned in IRC in #buddypress-dev by imathfromparis. View the logs.
10 years ago
#15
@
10 years ago
I've been playing with imath's patch for the past day and overall it's pretty good.
I came across a few bugs and have added a few enhancements in 02.patch
.
02.patch
does the following:
- Fix issues with querying for terms when not on the root blog
- In the
BP_Terms
class, I have removed thesetup_globals()
method and all class properties relating to the taxonomy tables and replaced it withswitch_to_blog()
/restore_current_blog()
instead. This is way more reliable.
- In the
- Fix issues with the group tag box if
BP_ROOT_BLOG
is not 1.- Adds
BP_Terms::get_terms_to_edit()
andbp_core_get_terms_to_edit()
.bp_core_get_terms_to_edit()
is used inbp_tags_meta_box()
in place ofget_terms_to_edit()
.
- Adds
- Registers the "Groups" admin menu on the root blog's dashboard
- I actually think this makes a whole lot of sense because as an admin, sometimes I won't be in the network admin area and will need to do some administrative stuff in the root blog dashboard. Need some feedback regarding multiblog.
- Registers the "Groups > Group Tags" menu
- Removes the code associated with displaying "Groups > Group Tags" page in the Network Admin area
- Instead, if in the Network Admin area and you click on "Groups > Group Tags", you get redirected to the root blog's "Group > Group Tags" page. This prevents having to duplicate the validation and saving of group tags in the network admin area (lines 1581 and on in bp-groups-admin.php are basically omitted from imath's patch`).
- When querying for a group tag, I've made things a little easier. In
bp_has_groups()
, you can pass the following:array( 'type' => 'tag', 'slug' => 'THE_TAG_SLUG' )
- Previously, you'd need to know how to use WP's tax query if you wanted to query for groups with a specific tag. The method above is much simpler.
- Moves the frontend "Group Tags" fields from the templates into a hook (see
bp_groups_tag_add_field_to_frontend_group_admin()
). This is so themes that have already overriden some of the group templates will inherit these new fields. - Modifies the look of a single group tag page on the group directory.
- If a group tag is being displayed, a "Tags" tab is added next to the "All Groups" and "My Groups" tabs and the group tag header is displayed before the group loop. This allows AJAX to work if you decide to click on "All Groups" or "My Groups".
- Some cookie manipulation is needed here to set the proper scope (see
bp_groups_tag_set_scope()
). Kinda hacky.
This patch is not commit-worthy by any means. I just wanted to put something up for review.
In future iterations, I'd like to break out all group tag code into its own file - bp-groups-tags.php
and make it so group tag functionality can be disabled with a filter.
We should split up the patch into two. The register taxonomy code, BP_Terms
class and its related functions could be committed for 2.1 to lay the groundwork for group tags in 2.2.
And in the spirit of boonebgorges, we need unit tests ;)
This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.
10 years ago
This ticket was mentioned in IRC in #buddypress-dev by imathfromparis. View the logs.
10 years ago
This ticket was mentioned in IRC in #buddypress-dev by bgorges. View the logs.
10 years ago
#20
follow-up:
↓ 21
@
10 years ago
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).
#21
in reply to:
↑ 20
@
10 years ago
Replying to 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-minded folks.
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.
#22
@
10 years ago
r-a-y,
I've tested your patch. It's working fine. There's some notices due to get_queried_object()
. I got rid of them resetting it from bp_core_load_template()
. But not sure it's the right move.
Personally, i don't really like to edit tags from the root blog admin, and then go back to network admin to edit a group, and then go back to root blog admin to edit tags... But i think it's the only way to do it without copy/pasting the edit-tags.php in the group tags admin function (what i've done in 4017.patch).
I've tried another way, and thought i found an alternative to stay in network admin to edit tags, by using a function like this :
function bp_groups_admin_tags_load() { $post_type = 'bp_group'; $taxnow = $taxonomy = 'bp_group_tags'; require_once( ABSPATH . 'wp-admin/edit-tags.php' ); exit(); } add_action( "load-$hook", 'bp_groups_admin_tags_load' );
At first it seemed to work fine, but AJAX, bulk actions, & search was failing. At several places WordPress checks for 'edit-tags.php'
:( So unless we have this file in network admin, i think your approach is the best.
I'm adding an updated version of your patch to latest trunk.
#24
@
10 years ago
So, not being able to edit a tag from the network admin was really annoying me!
I think 4017.03.patch is making it possible without adding too much copypasta of edit-tags.php
like it was the case in 4017.patch.
In 4017.03.patch, i just add some code to handle admin actions before including edit-tags.php
, see bp_groups_admin_tags_load()
function. This patch needs javascript to be enabled on the browser, as it needs to change some form attributes or inputs. In an ideal world, if WordPress was adding filters/actions to :
WP_List_Table->search_box()
in order to allow us to add a new hidden field to hold the page parameter.- the action parameter of
form#addtag
as today it's set toedit-tags.php
which is not available in network admin. - the action parameter of
form#edittag
inedit-tag-form.php
as today it's set toedit-tags.php
which is not available in network admin.
That said, if javascript is enabled, everything works fine :)
r-a-y, about :
array( 'type' => 'tag', 'slug' => 'THE_TAG_SLUG' )
I'm not sure, as the type
parameter is used to filter the order of the groups listed (alphabetical, last active...) As a result, when viewing the group tags page, changing the orderby dropdown value doesn't sort the groups list. Reason why, i've disabled it if on a groups tag page in this version of the patch.
Finally i have a doubt about the way i reset :
$wp_query->queried_object
- and
$wp_query->queried_object_id
to avoid notices when viewing a group tags page.
This ticket was mentioned in Slack in #buddypress by imath. View the logs.
10 years ago
#26
@
10 years ago
I hope no one will mind that I've opened a separate ticket for the taxonomy-wrapper stuff: #6028. I think we can and should fast-track that discussion, and not let the progress on this ticket (which I think is also good) hold up that one.
This ticket was mentioned in Slack in #buddypress by boone. View the logs.
10 years ago
This ticket was mentioned in Slack in #buddypress by mamaduka. View the logs.
9 years ago
#33
@
9 years ago
- Keywords has-patch has-unit-tests added; needs-refresh needs-testing removed
This is first pass for Groups Type taxonomy API, it's very similar to Member type API.
- Introduces API
group_*_type()
functions. - New
groups_type_exists()
function, which makes it possible forgroups_set_type()
andgroups_remove_type
to accept string or array of types. - Introduces
group_type
,group_type__in
andgroup_type__not_in
arguments forBP_Groups_Group::get()
.
This ticket was mentioned in Slack in #buddypress by mamaduka. View the logs.
9 years ago
#35
@
9 years ago
@Mamaduka Patch looks like a great start. Can we move discussion to #6784? The current ticket is more about group *tags*.
#36
@
9 years ago
@boonebgorges ugh, sorry got little bit confused with comments and provided examples. Happy to continue working in #6784.
@imath also happy to help here.
#39
@
8 years ago
@imath's experimental group taxonomy plugin https://github.com/imath/bp-groups-taxo has been refreshed for 2.7 and we're looking to give it a trial run. We intend to allow multiple taxonomies on groups as there are several things we're doing in group meta that might be better done with a custom taxonomy. I believe that this capability supplements group type. The question is should custom taxonomy support remain a plugin or could it move into BP?
This plugin has some differences from group types in implementation - it does not use blog switching - that might need reconsideration if moving into BP proper.
We've already implemented an Academic Interests custom taxonomy for users that we would like to add to groups. We would then create a similar plugin for sites. This would allow us to recommend groups and sites to a user based on their stated interests.
#40
@
8 years ago
- Keywords needs-patch added
@rekmla Thanks for updating here on your progress.
It would be fantastic to roll something like bp-groups-taxo into BuddyPress. bp-groups-taxo does two different kinds of things:
- It introduces logic that allows custom taxonomies to be assigned to BP groups (such as tying tax_query into group queries)
- It introduces a *specific* custom taxonomy to groups: Group Tags
The way that bp-groups-taxo does it doesn't really separate these things out in a complete way, though. So, while it's necessary to do some version of (a) in order to do (b), it's not really possible to use (a) to register additional custom group taxonomies - you have to have another full version of the plugin up and running, with taxonomy name changed. (I know, I've tried ;) )
I could imagine introducing the functionality described here in phases, so that general support for group taxonomies is introduced in a developer-facing way in one version of BP, and the Group Tag taxonomy and supporting UI is rolled out sometime later.
This plugin has some differences from group types in implementation - it does not use blog switching - that might need reconsideration if moving into BP proper.
Yes, unfortunately we need the blog-switching logic, to account for things like the Groups widget and other cases where group queries might be run on a non-root blog. But this logic is already built into BP's taxonomy wrapper functions https://buddypress.trac.wordpress.org/browser/trunk/src/bp-core/bp-core-taxonomy.php. So a good chunk of bp-groups-taxo could be rewritten to use these BP functions.
Sounds like a great idea. Looking forward to checking it out.