Make BP Groups into WP Custom Taxonomies

[sooskriszta]

Make some key components into CPTs:

• Groups
• Messages

...

[boonebgorges]

I'll leave this ticket open for discussion and for proof-of-concept patches, if anyone would like to contribute.

[chrisclayton]

Related discussion: ​http://bpdevel.wordpress.com/2012/03/05/custom-post-types-yesno/

I think were better off keeping current implementation and just continue making admin menus for messages and other components. (Like Activity and Groups). I believe we shouldn't fix what isn't broken, and i cant see any added benefits to moving them to CPT's. That's my 2c. Anyone disagree?

[sooskriszta]

@chrisclayton Thanks for the bpdevel link. Very useful discussion there.

I will refocus this particular ticket squarely on Groups. The humble kick-off suggestion is to make Groups into Custom Taxonomies, 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

[chrisclayton]

thanks @sooskriszta, you made some great points.

But, regarding making things easier for developers and WP users can I point you to Boones comment on that same post above? ​http://bpdevel.wordpress.com/2012/03/05/custom-post-types-yesno/#comment-2418

Also regarding more developers pitching in - refer to JJJ's comment here -​http://bpdevel.wordpress.com/2012/03/05/custom-post-types-yesno/#comment-2419

If this ticket is the same as #4017 (which I think is better than moving them to CPT's or anything) then this should be closed as duplicate. Is it the same or different?

[sooskriszta]

@chrisclayton

I read those comments and they don't quite address the issues above, except tangentially.

My primary concerns are:

• BuddyPress is not particularly easy to use. Even in cases when there are some features built in, they are often hidden behind things like filters. So while this functionality is "available", it is not usable for the average community owner. Moving to CPTs helps greatly reduce the "potential" workload for making BuddyPress user-friendly.
• There is some basic and some advanced functionality that many installations need. With CPTs this comes baked in. Similar results can be obtained in current architecture, but there would be need to go through many hoops.

@johnjamesjacoby 's post above points more towards the arguement about greater developer participation. Admittedly, that is more of a conjecture, and it is entirely possible that the move to CPTs does absolutely nothing to increase developer participation.

Similarly @boonegorges 's message is also an entirely different take on what's meant by "making it easier on developers". As mentioned above the primary benefit is that much stuff would come *almost* automatically, and developers won't have to worry about coding, testing or maintaining it.

Yes, duplicate. Somehow I forgot about that one. Closing.

Duplicate of #4017