[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
Comment:
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:
http://codex.buddypress.org/developer/loops-reference/the-activity-stream-
loop/#filtering-examples
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
activity.
So i'm attaching 5603.02.patch because i strongly think it's the right
move.
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