[buddypress-trac] [BuddyPress Trac] #3856: Saving activity update action as an array in db

[buddypress-trac]

#3856: Saving activity update action as an array in db
-----------------------------------+------------------
 Reporter:  modemlooper            |       Owner:
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  2.0
Component:  Activity               |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
-----------------------------------+------------------

Comment (by imath):

 Replying to [comment:14 boonebgorges]:
 > It'd be great to get initial feedback on the technique I've sketched
 here. Thanks.

 Hi boonebgorges. First: thanks a lot for the great work :)

 I've tested the patch, and the first thing i wanted to check was to join a
 group and immediately deactivate the group component to see what was
 happening, because i've seen that the format callback are in the group
 component.
 And this is what i got when i refreshed the activity stream:
 [[Image(https://farm4.staticflickr.com/3703/12857838984_c3ccb25e3c_z.jpg)]]

 Something happened 3 minutes ago :)

 So i thought about it, at first i've tried a patch to remove the activity
 that was concerning inactive components. Although i really think, that
 this is something we should do like the check we're doing in the
 notifications component thanks to the function
 {{{bp_notifications_get_registered_components()}}}, i thought about
 plugins. If we were to do that, then a lot of plugins wouldn't have their
 activity displayed although they're activated.
 So i've tried a second patch using
 {{{buddypress()->deactivated_components}}} and "array_intersecting" it
 with a hardcoded array of components that are generating activities. It
 was working, but i realized i wasn't in the scope of this ticket. I've
 checked the way activity was displayed in case a component was inactive,
 and they are actually displayed :)

 So i thought well, having "something happened 3 minutes ago" will avoid
 having for instance a link to a group that would lead to a 404 :)

 So i've tested to create some callbacks from a plugin and it's working
 really great. Then something seemed weird to me. But i may be wrong about
 my interpretation of the code. So sorry if i am!!

 1) I thought it wasn't necessary to create an activity_meta in case the
 action_data was an empty array. So i've added a check.

 2) then i wondered why in the new {{{bp_activity_add()}}} we have :
 {{{
 $activity->action = isset( $action ) ? $action :
 bp_activity_generate_action_string( $activity );
 }}}

 Because $action is always set, if not passed in arguments to
 {{{bp_activity_add()}}} then it defaults to {{{''}}} so the
 {{{bp_activity_generate_action_string( $activity )}}} part is never played
 and as a result activity_update and joined_group has a blank action in
 activity table.

 3) So i've imagined (may be i was wrong) that you wanted to keep on
 populating the action field in the activity table by generating the action
 thanks to the callback function. So i've replaced by a {{{ ! empty()}}}
 check and just above set the var {{{$activity->action_data}}} to
 {{{$action_data}}} and it created the action in the activity table field.

 Just in case i'm not wrong, i'm attaching 3856.02.diff

 Finally, i think :
 When this very interesting improvement will be implemented, it will surely
 require a message to plugin developer to enjoy it. So plugin developer
 will begin to use bp_activity_set_action() to register their activities,
 may be we can also improve the templates (activity/index,
 members/single/activity & groups/single/activity) to make this use avoids
 them to hook the "filter" actions. And why not carry on by only displaying
 activities for the active components.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3856#comment:16>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac