[buddypress-trac] [BuddyPress Trac] #6630: Issue posting comment on links using buddypress

[buddypress-trac]

#6630: Issue posting comment on links using buddypress
----------------------------------+-----------------------
 Reporter:  camaro4d              |       Owner:
     Type:  defect (bug)          |      Status:  reopened
 Priority:  normal                |   Milestone:  2.4
Component:  Component - Activity  |     Version:  1.7
 Severity:  normal                |  Resolution:
 Keywords:  needs-patch           |
----------------------------------+-----------------------
Changes (by boonebgorges):

 * keywords:  needs-testing has-patch => needs-patch


Comment:

 6630.patch looks like the wrong fix to me.

 The discrepancy between the two uses of the filter was introduced in
 [9160]. The filter was originally introduced to the AJAX callback in
 [2552], using 3 params, not 4.

 In [2692], the same filter was added to
 `bp_activity_action_post_update()`, using the same pattern of 3
 parameters.

 It's not a very well-designed filter, and has probably caused bugs over
 the years. Perhaps it ought to have been written with `false` for the
 default parameter from the start. But I don't think there's a pressing
 reason to change it - it's certainly possible to use it the way it is.
 (MrMaz managed to use it!) [9160] looks like a regression to me.

 I'm not sure whether a different approach is needed for #6021. If so, it
 probably looks like this:

 {{{
 ...
 } else {
     $posted_object = $_POST['object'];
     $activity_id = apply_filters( 'bp_activity_custom_update',
 $posted_object, $item_id, $content );
     if ( $posted_object === $activity_id ) {
         $activity_id = null;
     }
 }
 }}}

 If we go this route, the filter needs to be carefully documented to
 explain this quirk.

 Alternatively, let's introduce a new filter that does what [9160] does.

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