Capabilities Undefined Offset error with BBpress

Hi there,
This is a bbPress bug caused because they didn’t handle the idea of meta capabilities being used which is why so many plugins are getting support tickets for it.

Let’s take a look at the first one for example:
> Notice: Undefined offset: 0 in ./wp-content/plugins/bbpress/includes/topics/capabilities.php on line 80

So here’s the code for that:

function bbp_map_reply_meta_caps( $caps = array(), $cap = '', $user_id = 0, $args = array() ) { 
 
  // What capability is being checked? 
  switch ( $cap ) { 
 
      /** Reading ***********************************************************/ 
 
      case 'read_reply' : 
 
          // User cannot spectate 
          if ( ! user_can( $user_id, 'spectate' ) ) { 
              $caps = array( 'do_not_allow' ); 
 
          // Do some post ID based logic 
          } else { 
 
              // Get the post 
              $_post = get_post( $args[0] ); 
              if ( !empty( $_post ) ) { 

So what happens here is since another plugin, in this case MonsterInsights, but many plugins also use them, are registering a meta capability, this capability will need to be resolved.

When that happens, the map_meta_filter is called here: https://core.trac.www.ads-software.com/browser/tags/4.9/src/wp-includes/capabilities.php#L572

Now, notice the $args param on that. Since MonsterInsights is a custom meta meta_cap, what will happen is $args would be populated here: https://core.trac.www.ads-software.com/browser/tags/4.9/src/wp-includes/capabilities.php#L554.

However, notice how this is surrounded by a check for custom post types. In order for $args to be populated, since $args is for passing in custom post type meta meta_cap assignments, it will be empty since the MonsterInsights screen is not a custom post type.

Therefore in bbPress on the lines I had above, $args is going to be empty, and since they don’t handle not being on a post, the $args[0] is going to be undefined and throw the notice you mentioned.

What they need to do is put a check that says

if ( empty( $args[0] ) ) { 
   return $caps;
}

or something like that above the use of $_post = get_post( $args[0] ); so that it circumvents the check. They also need the same fix in the other file as well.

I’ll see if I can submit that to them to see if they can ship that.

A ticket for BBPress has been opened here: https://bbpress.trac.www.ads-software.com/ticket/3190#ticket

What an outstanding response!
Thank you so much. This completely clarifies things for me.
And thank you for taking it up with bbPress!

Not a problem! We’re always happy to help ??

bbPress has just earmarked this to go into their next major release, 2.6. I’ll try to get them a patch file today if I can to expedite that merge process.

If you haven’t done so already, if you’ve been using MonsterInsights, we really appreciate reviews (good as well as bad ones). Good ones help our overall plugin rating, which in turn really helps us since there’s a lot of bad ratings for the plugin from before we took over development and rewrote it. Bad ones help us find areas we can improve on (generally, though sometimes people just write “I hate it” which honestly doesn’t help us out too much). You can leave reviews (as well as edit yours at any time) on https://www.ads-software.com/support/plugin/google-analytics-for-wordpress/reviews/

-Chris

• This reply was modified 6 years, 9 months ago by chriscct7.

Actually I question your answer. Doing some investigation in the same error and found a bug in your plugin. you are calling current_user_can() incorrectly.

In version 6.2.7 of your plugin. In the file class-am-notifications.php in the function get_remote_notifications() line 92 you have the following:

if ( ! current_user_can( apply_filters( ‘am_notifications_display’, is_super_admin() ) ) ) {

In the inner command you have a filter which will return true or false.
apply_filters( ‘am_notifications_display’, is_super_admin() )

Then you are passing this true/false into the current_user_can() as the first parameter. This is wrong. You should be passing a string like ‘manage_options’ or ‘edit_posts’ etc. a capability.

Down the line when other plugins who are subscribed to the ‘map_meta_cap’ filter receive true or false as the $cap parameter (second) instead of a string.

This is a separate issue from the one being experienced above (there are other tickets, notably a conflict with the Advanced Access Manager plugin that we were working on testing that do have this issue which is a valid one, and one we’ve issued a fix for).

The bbPress one has been patched already for the upcoming bbPress 2.6 release.

-Crhis