[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