bp_get_the_body_class ignoring other plugins' classes on BP-specific pages

[DJPaul]

The bp_get_the_body_class() function doesn't merge classes added by other plugins to the body_class filter when viewing a BuddyPress-specific page.

This looks to be intentional but it causes compatibility problems with other plugins that add classes to this filter that are expected to be present regardless of whether the user's viewing a BuddyPress-generated page or not.

A plugin that demonstrates this problem is Achievements v3.2.1 -- ​http://downloads.wordpress.org/plugin/achievements.3.2.1.zip -- to recreate, create an achievement, award it to yourself. Visit the root of your site; you'll get a overlay/pop-up window. Click on the outside of the window to close it. Then visit a BP page (e.g. /activity) and try to do the same. It doesn't work because the "achievement-notifications" class is missing from body.

[boonebgorges]

Odd. I wonder why we would intentionally do this. It seems pretty clearly wrong. Would we introduce any oddness by merging instead of starting from scratch?

[DJPaul]

Also #5127

[unsalkorkmaz]

For people looking temporary solution:

add_action("wp_footer", "firmasite_buddypress_wpadminbar_fix");
function firmasite_buddypress_wpadminbar_fix(){
	if (is_buddypress() && is_admin_bar_showing()) { ?>
	<script>
	jQuery(document).ready(function() {
		jQuery("body").addClass("admin-bar");
	});
	</script>
	<?php 
	}
}

[sgr33n]

Even about classes. Is it correct that even if I'm on my own profile or of another user there are these two classes: my-activity just-me?

[needle]

I'm not qualified to answer the question of whether it would be better to merge the class arrays (I assume that there could be knock-on effects in various themes if the default WordPress classes are maintained) but the patch I've attached at least addresses the issue of preserving the 'admin-bar' and 'no-customize-support' classes when they are present.

As for plugins that inject a class or classes via the 'body_class' filter, it is trivial for the plugin authors to use a priority greater than 10, thus filtering after BuddyPress has done its stuff. They may, of course, not know that their plugin is being used in a BuddyPress context. Hmm.

[boonebgorges]

Thanks, needle. Your patch is conservative, but probably better than doing nothing. Let's settle this for 2.0.

[r-a-y]

needle's patch also fixes problems with Twenty Fourteen's header in #5284 due to the missing 'admin-bar' body class.

I'd say this is commit-worthy for 1.9 and for 2.0, we can look at how merging WP's classes with BP's might be better.

[boonebgorges]

In 7663:

Don't wipe out admin-bar and no-customize-support body classes

See #4929

Props needle

[DJPaul]

Let's just merge the arrays and be done with it? I still think this was just an oversight in the original version.

[DJPaul]

After testing with merging all the possible body class variables, wpcore adds the following on a typical request: "page page-id-123 page-template-default" which seems OK. It also doesn't remove classes added by other plugins, which is a big win.

[djpaul]

In 8068:

Core: merge custom body classes with WordPress' defaults.

Until 1.9, we overrode all the custom body classes that are added to the theme, and replaced them with BuddyPress-specific classes.
With 1.9 in r7663, we manually added a couple of WordPress core classes back to fix compatibility problems with certain themes (notably, Twenty Fourteen). However, body classes added by other plugins were still removed.

This change merges BuddyPress' body classes into those provided by WordPress core, and those from any other plugins.

Fixes #4929 and #5204