bp_nouveau_get_activity_entry_buttons not targeting given $activity_id

[bouncingsprout]

When we filter on bp_nouveau_get_activity_entry_buttons, I would expect the activity ID passed to be usable, so we can offer a bespoke button for a particular activity, or set of activities.

Thus, I would expect the following code to add a button only where the activity ID is 575:

<?php
add_filter( 'bp_nouveau_get_activity_entry_buttons', 'add_button', 999, 2 );
function add_button( $buttons, $activity_id ) {
        echo 'This is activity ID: ' . bp_get_activity_id();
        if ( $activity_id == '575' ) {

                $buttons['new'] = array(
                        'id'          => 'new',
                        'component'   => 'activity',
                        'button_attr' => array(
                                'data-id'    => bp_get_activity_id(),
                        ),
                        'link_text'   => sprintf(
                                '<span>%1$s</span>',
                                'Shouldn\'t exist more than once, so we can test against activity ID each time',
                        ),
                );

                return $buttons;
        } else {
                return $buttons;
        }
}

The button correctly appears on activity 575, but then also for each activity afterwards. Worse, the data-id attribute is permanently 575, meaning no actions can be taken on that activity, using that method (for instance, via ajax).

Screenshot attached of the result. Clean install of BuddyPress, default theme.

If this is expected behaviour, there may be some scope to clear up why we are passing an unusable activity ID in comments/docs.

Thanks everyone!

Ben Roberts

[bouncingsprout]

Screenshot of result of filter

[imath]

Hi @bouncingsprout

Thanks for your feedback. That's because the button group is using object cache. I guess this is making things harder: we should probably stop caching button group args.

Let's think a bit more about it during 11.0.0. In the meantime, ​8716.patch is a first fix.

[bouncingsprout]

Thanks @imath!

Is this a new thing? I don't remember this happening in previous versions, and it isn't happening in the BuddyBoss platform so I'm assuming this is a change after their 'fork'.

Is there anything we can do on the filter side? Any way to disable the button group cache there?

[imath]

In 13338:

BP Nouveau: improve the BP_Buttons_Group class

Make sure filtering bp_nouveau_get_activity_entry_buttons to create a
button for a specific item's loop is not propagated to other items.

As the buttons of the group are cached, we need to eventually ignore some
cache data if this filter is used to generate button for specific items of
the loop instead of all items.

Props bouncingsprout

Fixes #8716