Skip to:
Content

Opened 2 years ago

Last modified 4 months ago

#4017 new defect (bug)

Group taxonomy

Reported by: boonebgorges Owned by: boonebgorges
Milestone: Future Release Priority: normal
Severity: major Version:
Component: Groups Keywords:
Cc: vpundir@…, e.soghe@…

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.

Change History (6)

comment:1 sooskriszta2 years ago

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

comment:2 sooskriszta17 months 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 sooskriszta17 months 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 boonebgorges17 months 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 Sadr17 months ago

  • Cc e.soghe@… added

comment:6 johnnymestizo4 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

Note: See TracTickets for help on using tickets.