Use CPTs for status updates

[terraling]

I've been reading through old discussions about adopting CPTs (such as on ​http://bpdevel.wordpress.com/2012/03/05/custom-post-types-yesno/ or tickets such as ​https://buddypress.trac.wordpress.org/ticket/4017 and ​https://buddypress.trac.wordpress.org/ticket/3460).

It's an old topic & the consensus seems to be that net/net there is not much aside from possibly Groups that would benefit from the transition.

But from my perspective (making a bespoke site based on BP rather than making & selling customisable BP themes for a general audience) it seems that activity updates could usefully be transitioned. I'm not talking about the Activity component generally, I'm specifically referring to status udpates.

When starting out with WP you learn that basically everything is a post (or a comment on a post). BP status updates are not.

It's not new but I only came across P2 from automattic a few weeks ago, where status updates are just posts (via the front-end).

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), and developers wouldn't have to hack the output and CSS for two comment systems to make them look and work the same.

Correct me if I'm wrong but 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.

The activity of posting and commenting on updates would still be recorded, but the content itself wouldn't be stored in the activity table anymore, as per the current discussion on recording other CPT activity.

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.

[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 ​https://buddypress.trac.wordpress.org/ticket/5429#comment:2

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 another.

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.

[terraling]

Thanks Boone for your comprehensive response.

The only point which I'm not sure I agree with is

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.

It would mean storing the content of status updates in the posts table instead of the activity table. If you have 10,000 status updates, does it matter which table they are stored in?

I haven't looked under the hood but presumably P2 stores all of the 'updates' as posts.

Anyway, I understand from your other comments the problems with implementing this, feel free to close the ticket.

[boonebgorges]

It would mean storing the content of status updates in the posts table instead of the activity table. If you have 10,000 status updates, does it matter which table they are stored in?

By itself, maybe not. But a P2 site is generally a single-purpose entity: the only thing it does is host a P2. A BuddyPress site potentially does many things, and has lots of plugins that are using the posts table for stuff. (Like, say, bbPress.) This could cause special kinds of problems for plugins that then need to query wp_posts data in specific sorts of ways that don't scale well. This is less likely to happen with the activity table, because (1) fewer plugins are using it for stuff, and (2) it's better designed for complex queries of the type that are likely to be made at it.

Going to close the ticket. Thanks very much for the discussion points.