Skip to:

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#4569 closed enhancement (duplicate)

Make BP Groups into WP Custom Taxonomies

Reported by: sooskriszta's profile sooskriszta Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Core Keywords:
Cc: chrisclayton, vpundir@…, e.soghe@…, brajesh@…


Make some key components into CPTs:

  • Groups
  • Messages


Change History (8)

#1 @boonebgorges
12 years ago

  • Milestone changed from Awaiting Review to Future Release

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

#2 @chrisclayton
12 years ago

  • Cc chrisclayton added

Related discussion:

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 major added benefits that make moving them to CPT's worthwhile. That's my 2c. Anyone disagree?

Last edited 12 years ago by chrisclayton (previous) (diff)

#3 @sooskriszta
12 years ago

  • Cc vpundir@… added
  • Summary changed from Deploy custom post types to Make BP Groups into WP Custom Taxonomies

@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):

#4 @Sadr
12 years ago

  • Cc e.soghe@… added

#5 @chrisclayton
12 years ago

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?

Also regarding more developers pitching in - refer to JJJ's comment here -

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?

#6 @sooskriszta
12 years ago

  • Resolution set to duplicate
  • Status changed from new to closed


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

#7 @johnjamesjacoby
12 years ago

  • Milestone Future Release deleted

#8 @sbrajesh
12 years ago

  • Cc brajesh@… added
Note: See TracTickets for help on using tickets.