[buddypress-trac] [BuddyPress] #3980: bp_activity_at_name_filter_updates() causes activity to be saved twice

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Tue May 22 13:03:41 UTC 2012


#3980: bp_activity_at_name_filter_updates() causes activity to be saved twice
--------------------------+------------------
 Reporter:  r-a-y         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  1.6
Component:  Activity      |     Version:  1.5
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |
--------------------------+------------------

Comment (by boonebgorges):

 r-a-y, you've now made some modifications to the Group Email plugin that
 works around this BP issue. Having spent some time with workarounds, do
 you have ideas about a straightforward core fix? I'm pretty sure that the
 reason I used `bp_activity_after_save` is because the activity_id is not
 available before the save() method is run, and we need that activity id to
 save the mention to usermeta. See #2082, r4367

 Along the lines of what DJPaul suggests, maybe split the process of
 identifying/linkifying mentions from the process of storing them to
 usermeta:
 - hook into bp_activity_before_save
 - look for mentions
 - If none are found, do nothing and return to the save() function
 - If mentions are found:
     - do the necessary link-ifying to the content
     - unhook the current function from bp_activity_before_save (to prevent
 infinite loops)
     - hook a second function, for recording the mention(s) to usermeta, to
 bp_activity_after_save
     - and run the save() function again

 This workflow is pretty clunky (I am not a fan of the hook-then-unhook-to-
 prevent-recursion trick), but it seems like it would work with relatively
 little overhead.

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


More information about the buddypress-trac mailing list