[buddypress-trac] [BuddyPress] #4600: children of activity comments not populated with BP_Activity_Activity::get()

[buddypress-trac]

#4600: children of activity comments not populated with
BP_Activity_Activity::get()
--------------------------+-----------------------
 Reporter:  sboisvert     |       Owner:
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  1.7
Component:  Activity      |     Version:  1.7
 Severity:  minor         |  Resolution:
 Keywords:                |
--------------------------+-----------------------

Comment (by boonebgorges):

 Ah. The problem is that the patch was only tested against the main,
 sitewide activity streams. On those streams, we don't show comments as
 top-level items. The behavior on user-specific activity streams is
 different: comments *are* shown as top-level items, as well as being shown
 in the context of their correspending top-level parent.

 Personally, I think that our method of showing activity comments on the
 user activity stream is a little bit wonky anyway - even aside from the
 bug noted by r-a-y, activity comments will show up twice (in the top-level
 parent tree, as well as in the chronological flow). This is probably not
 the time or place to fix this UX issue, but it does at least show that
 there's no perfect way to accomplish what we want.

 Instead of r-a-y's brute-force patch, maybe we could do something like the
 following: BP_Activity_Activity::get() could take another parameter (call
 it `'recurse_comments'` or something like that). When true, comments are
 *always* pulled up for each item in the stream, even if the item is an
 activity_comment; when false, comments are skipped for activity_comments.
 The value would default to false, and in the context of the user activity
 page, we would manually set it to false (because we are showing
 activity_comments in the chronological flow). This is not incredibly
 elegant, but it's flexible, and allows us to maintain backward
 compatibility while also fixing the (IMO more serious) bug that was the
 original cause of the ticket.

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