[buddypress-trac] [BuddyPress Trac] #5632: Use CPTs for status updates

buddypress-trac noreply at wordpress.org
Mon May 12 13:08:39 UTC 2014

#5632: Use CPTs for status updates
 Reporter:  terraling    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Activity     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |

Comment (by boonebgorges):

 terraling - Thanks for the thoughts.

 > If BP status updates were just posts (albeit CPTs), then commenting
 would already be integrated, you wouldn't need a parallel BP commenting
 system (and bridges between them),

 We support replies to *all* activity types, not just updates. So we
 couldn't do away with activity_comment.

 > developers wouldn't have to hack the output and CSS for two comment
 systems to make them look and work the same.

 I wonder if this is something that most developers are actually doing.
 I've never personally had a request to skin these two exactly the same.
 That said, I'm not opposed to exploring the idea of attempting to inherit
 some comment markup from the WP theme if it's technically feasible.

 > it would make it more straightforward for developers to enable the oft-
 requested feature of media (even galleries, not just single embeds) in
 status updates than it appears to be at the moment, and you'd also benefit
 from any upstream enhancements in WP core.

 This is only true if you make a number of other assumptions. First, we'll
 only get all the front-end goodies if we actually use core markup (which
 is doubtful); if not, we can just use `wp_editor()`, which doesn't require
 storage as a CPT anyway. Second, this assumes that we actually want to
 store BP content using the same schema as WP content, which I don't think
 is the case. See eg

 On the specific subject of attachments/media, I do think that something is
 coming to BP, and I think it will leverage a lot of core tools, but I
 don't think that moving to CPTs for status updates will help one way or

 > I don't know what the performance implications are. It implies an
 initial query to retrieve the required ids from the activity table and a
 second query which retrieves the content for those ids, not sure if or how
 that is very different from what happens under the hood now.

 For the most part, the Activity component is an aggregator. When you query
 activity content, it pulls content from the activity table; aside from
 some component-specific pre-fetching, it doesn't actually touch the source
 data at all. So from the point of view of activity queries, it wouldn't
 really make a difference. This change does have the potential to add huge
 amounts of data to the core posts and postmeta tables, which I think is a
 serious negative.

 My take on this is, as in the case of most other BP content, that while we
 *could* move to CPTs for this content, the benefits are too meager (in
 this case, I'd argue there are really very few benefits at all) to justify
 the costs. But I'd be happy to entertain counterarguments.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5632#comment:1>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list