Skip to:
Content

Opened 3 years ago

Last modified 8 months ago

#4017 new enhancement

Group taxonomy

Reported by: boonebgorges Owned by: boonebgorges
Milestone: Future Release Priority: normal
Severity: major Version:
Component: Component - Groups Keywords: has-patch
Cc: vpundir@…, slava.abakumov@…, vivek@…

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 (4)

4017.patch (80.9 KB) - added by imath 13 months ago.
4017.02.patch (65.2 KB) - added by r-a-y 12 months ago.
Updated 02.patch to remove reference to a non-existent function
4017.02.r9092.patch (68.1 KB) - added by imath 8 months ago.
4017.03.patch (75.9 KB) - added by imath 8 months ago.

Download all attachments as: .zip

Change History (31)

comment:1 @sooskriszta3 years ago

Sounds like a great idea. Looking forward to checking it out.

comment:2 @sooskriszta3 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

comment:3 @sooskriszta3 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):

comment:4 @boonebgorges3 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.

comment:5 @Sadr3 years ago

  • Cc e.soghe@… added

comment:6 @johnnymestizo19 months 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

comment:7 @boonebgorges14 months ago

  • Type changed from defect (bug) to enhancement

comment:8 @imath13 months 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

comment:9 @slaFFik13 months ago

  • Cc slava.abakumov@… added

comment:10 @ircbot13 months ago

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

comment:11 follow-up: @r-a-y13 months 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?

comment:12 in reply to: ↑ 11 @imath13 months 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()

comment:13 @imath13 months 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 :

I haven't tested the patch on non multisite configs.

@imath13 months ago

comment:14 @ircbot13 months ago

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

comment:15 @r-a-y12 months 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 the setup_globals() method and all class properties relating to the taxonomy tables and replaced it with switch_to_blog() / restore_current_blog() instead. This is way more reliable.
  • Fix issues with the group tag box if BP_ROOT_BLOG is not 1.
    • Adds BP_Terms::get_terms_to_edit() and bp_core_get_terms_to_edit(). bp_core_get_terms_to_edit() is used in bp_tags_meta_box() in place of get_terms_to_edit().
  • 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 ;)

@r-a-y12 months ago

Updated 02.patch to remove reference to a non-existent function

comment:16 @ircbot12 months ago

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

comment:17 @ircbot11 months ago

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

comment:18 @sooskriszta9 months ago

  • Cc vivek@… added

comment:19 @ircbot9 months ago

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

comment:20 follow-up: @DJPaul9 months 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).

comment:21 in reply to: ↑ 20 @boonebgorges9 months 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.

comment:22 @imath8 months 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.

@imath8 months ago

comment:23 @Sadr8 months ago

  • Cc e.soghe@… removed

comment:24 @imath8 months 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 to edit-tags.php which is not available in network admin.
  • the action parameter of form#edittag in edit-tag-form.php as today it's set to edit-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.

Last edited 8 months ago by imath (previous) (diff)

@imath8 months ago

comment:25 @slackbot8 months ago

This ticket was mentioned in Slack in #buddypress by imath. View the logs.

comment:26 @boonebgorges8 months 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.

comment:27 @slackbot8 months ago

This ticket was mentioned in Slack in #buddypress by boone. View the logs.

Note: See TracTickets for help on using tickets.