[buddypress-trac] [BuddyPress] #4017: Group taxonomy

[buddypress-trac]

#4017: Group taxonomy
--------------------------+-----------------------------
 Reporter:  boonebgorges  |       Owner:  boonebgorges
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Groups        |     Version:
 Severity:  major         |  Resolution:
 Keywords:                |
--------------------------+-----------------------------

Comment (by boonebgorges):

 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.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4017#comment:4>
BuddyPress <http://buddypress.org/>
BuddyPress