Skip to:

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#4569 closed enhancement (duplicate)

Make BP Groups into WP Custom Taxonomies

Reported by: 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
6 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
5 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 5 years ago by chrisclayton (previous) (diff)

#3 @sooskriszta
5 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
5 years ago

  • Cc e.soghe@… added

#5 @chrisclayton
5 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
5 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
5 years ago

  • Milestone Future Release deleted

#8 @sbrajesh
5 years ago

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