[buddypress-trac] [BuddyPress Trac] #5603: Posting a new Activity causes activity-loop.php scope filters to be removed

buddypress-trac noreply at wordpress.org
Thu May 1 09:53:19 UTC 2014

#5603: Posting a new Activity causes activity-loop.php scope filters to be removed
 Reporter:  xyhavoc                              |       Owner:
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Activity                             |  Review
 Severity:  major                                |     Version:  2.0
 Keywords:  reporter-feedback has-patch 2nd-     |  Resolution:
  opinion                                        |
Changes (by imath):

 * keywords:  reporter-feedback => reporter-feedback has-patch 2nd-opinion


 Hi boonebgorges, xyhavoc

 I've checked the trouble, in bp.org forum the description xyhavoc made
 into this post was a bit unclear to me, i wasn't sure the problem was
 appearing when on the user's activity profile page.

 1/ I've just edited the codex, to remove the {{{bp_has_activities(
 'object=status' )}}} thing that was described in the filtering examples
 chapter in favor of the example of the activity updates see:

 I've done this because the object "status" does not exist anymore as it
 has been replaced by the last activity update a user made. Moreover i
 think this part was confusing, because it gave the impression we could use
 the activity loop without the {{{bp_ajax_querystring( 'activity' )}}}
 argument. This argument needs to be there otherwise the pagination is
 broken for instance. If you take this example :
 {{{bp_has_activities( '&action=activity_update' )}}}
 You will end up loading the same activities that are displayed on the
 stream when clicking on the load more button.
 Now @xyhavoc About the gist i've shared with you, as i've said it's my
 personal preference to not rely on templates to customize the activity
 loop in order to have more control on it. With your method all activity
 loops will be restricted with activity updates, with mine i can choose to
 restrict the user's profile one, the directory or the group's home one.
 I agree it didn't solve the issue and you're free to use the method of
 your choice.

 2/ The issue
 I chose not to enable heartbeat when on a user's profile because i thought
 it doesn't make sense to surcharge this part as to be usable it would
 require the user to open a new browser and post from this browser to see
 on the first browser that he posted a new activity. As a result i think
 heartbeat is only interesting when more than one user can post > Directory
 & in activity's single group page.
 boonebgorges, i saw & tested your patch, it seems to work fine, but i have
 the feeling this is not the best way to solve this. Explaining why:
 In bp-templates/bp-legacy/buddypress/buddypress-functions.php at line 714
 there's :
 } else {
         $activity_args = array( 'include' => $activity_id );
 And using your patch we'll never set this  $activity_args the way it's
 described in the else part. So i think the problem is the {{{isset}}}
 check that we should replace by a {{{ ! empty }}} one, this way we'll
 "arrive" in the else part described above. And concerning the user's
 profile i think we need to only get the activity the user just posted
 instead of all the activities the user posted since (we never know if the
 user is playing with 2 browser at the same time).
 Because this single update will dynamically update the "user status" or
 latest activity in member's header. So we need to be sure there's only one

 So i'm attaching 5603.02.patch because i strongly think it's the right

 xyhavoc, can you confirm 5603.02.patch is also fixing your issue ?
 boonebgorges, what do you think of my alternative approach ?

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

More information about the buddypress-trac mailing list