[buddypress-trac] [BuddyPress Trac] #5632: Use CPTs for status updates
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:
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
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/>
More information about the buddypress-trac