Activity stream "everything" filter assumes Groups component is active

[DJPaul]

For some types of activity, the activity stream "everything" filter will throw a fatal error when the Groups component is disabled.

Using the BuddyPress Default Data plugin, on a clean 1.6b2/3.4.1 non-ms install (accepting all install wizard defaults), create some data for the Groups component. Then deactivate the Groups component, and to the Activity page on the BP-Default theme.
If the filter is set to "everything", the following fatal errors occur:

[08-Jul-2012 19:53:00 UTC] PHP Fatal error: Call to undefined function groups_get_group() in /Users/paul/Sites/master/wp-content/plugins/buddypress/bp-activity/bp-activity-template.php on line 1065

Here is an example of an activity item that throws this error:
object(stdClass)#233 (19) { ["id"]=> string(3) "453" ["user_id"]=> string(2) "19" ["component"]=> string(6) "groups" ["type"]=> string(15) "activity_update" ["action"]=> string(188) "jason posted an update in the group The Shawshank Redemption" ["content"]=> string(25) "http://vimeo.com/19658300" ["primary_link"]=> string(33) "http://example.com/members/admin/" ["item_id"]=> string(2) "11" ["secondary_item_id"]=> string(1) "0" ["date_recorded"]=> string(19) "2012-07-08 19:46:08" ["hide_sitewide"]=> string(1) "0" ["mptt_left"]=> string(1) "0" ["mptt_right"]=> string(1) "0" ["is_spam"]=> string(1) "0" ["user_email"]=> string(15) "email18@aol.com" ["user_nicename"]=> string(5) "jason" ["user_login"]=> string(5) "jason" ["display_name"]=> string(14) "Jason Chaffetz" ["user_fullname"]=> string(5) "jason" }

[DJPaul]

We could check that the 'component' for an item exists. I don't know how to handle third-party activity types in this situation. It's also going to mess up pagination if we take inactivate components out of the results, so I think we should handle this in query.

For 1.6, I think we could add some bp_is_active() checks into bp_dtheme_activity_secondary_avatars() in DTheme's functions.php (to bail out if the component isn't active). This clears the fatal error and *seems* to allow everything to proceed correctly, though of course the link to the group in the activity 404s.

[DJPaul]

Attached a patch. Something like that.

[boonebgorges]

Let's try to get closer to the root of the problem. The fatal error arises because we're calling groups_get_group() when the groups component is disabled. So let's check for groups before calling that function. See 4335.02.patch. There should be no backward compatibility issues with this.

Third-party components take care of themselves automatically on deactivation. Our problem arises because we are making a function call to a function that does not exist. Plugins that attach themselves with action and filter hooks can't have this problem, since they won't be around anymore to call the non-existent functions. This is simply a case of BP's component leeching into each other in an abusive, privileged way (which is to say that, down the road, this sort of thing should be handled on a component-specific basis, where there's an apply_filters() on $alt, which can be filtered in the groups component.

[DJPaul]

4335.02.patch caused PHP Notices, so refactored in 4335.03.patch

[boonebgorges]

4335.02.patch caused PHP Notices

That's what I get for patching blindly. 03 looks like the right solution to me.

[djpaul]

(In [6175]) Avoid calling a Groups component function in the Activity stream if the Groups component has been disabled. Fixes #4335, props boonebgorges, DJPaul