[buddypress-trac] [BuddyPress Trac] #7192: Improve $args included in `bp_current_user_can` and `bp_user_can` filters.

buddypress-trac noreply at wordpress.org
Mon Aug 1 19:38:51 UTC 2016

#7192: Improve $args included in `bp_current_user_can` and `bp_user_can` filters.
 Reporter:  dcavins       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |

Comment (by dcavins):

 Replying to [comment:4 DJPaul]:
 > Patch missed removing `$blog_id` var on line 266 (as i look at it on
 trac with its line number).
 @DJPaul I was reading that as backcompat. If they pass an
 `$args['blog_id']`, use it for the `$args['site_id']` but unset it. Maybe
 we should throw a deprecation notice there in 2.8?

 > We also need to catch if the user isn't logged in.
 `current_user_can_for_blog` took care of this but we aren't using it any
 more. (line 280 of the patch in the trac view, again). I think an 0 might
 cause problems in WP `current_user_can` (it seems like relying on that
 would be undefined behaviour).
 Are you talking about passing a `user_id` of 0 to `user_can()`? Passing a
 0 for `user_id` should result in the same behavior as calling
 `current_user_can()` when no one is logged in:
 `user_can()`: https://core.trac.wordpress.org/browser/tags/4.5.3/src/wp-

 Huh, why is there no `user_can()` analog for
 `current_user_can_for_blog()`. I was wondering why we're doing multisite
 work in `bp_user_can()`. Interesting.

 @r-a-y: Let's work this out and get it committed to trunk. I'll attach a
 version of your patch that adds info to the filter docblock per
 @boonebgorges' suggestion.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7192#comment:5>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list