BuddyPress

… even if “Hide admin bar for logged out users” is set “Yes”.

To fix this, add 2 lines

if ( (int)get_site_option( 'hide-loggedout-adminbar' ) && !is_user_logged_in() )
return false;

at bp_core_add_admin_bar_css function (in wp-content/plugins/buddypress/bp-core/bp-core-cssjs.php) before line 16

It will be wonderful if this could be fixed in the next release.
Thanks in advance

@clojel

You shouldn’t really mod the core files, as they’ll be overwritten if you upgrade. Is there any filter you can hook on to instead as an interim solution?

Certainly though, this should be added to the trac as a potential bug to be looked at.

We have the same problem with child themes in secondary sites – we’ve turned off the admin bar, we don’t have any admin bar css being included in our child theme, but still it pulls in admin bar css code from bp-default and inserts the unwanted padding.

[As an aside: does anyone know where the code is that's injecting the admin bar css include into the header of child themes? Is it a hook on wp-footer?]

p.s. we have the problem in 1.2.5.2 as well

Hi Roger,
the admin bar is constructed in bp-core/bp-core-adminbar.php
the css file for this is in bp-themesbp-default_inccssadminbar.css

notepad++ is my friend

@chouf1 – yes, I know where the adminbar.css file is. Coda is my friend

The question was, why is adminbar.css being included in other themes (even none child ones) on a multisite network? What’s injecting it, and how do we turn it off.

e.g. My theme doesn’t explicitly link to adminbar.css, here’s the snippet from the header.php:

<link rel="profile" href="http://gmpg.org/xfn/11&quot; />
<link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'stylesheet_url' ); ?>" />
<link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>" />
<?php
	if ( is_singular() && get_option( 'thread_comments' ) )
		wp_enqueue_script( 'comment-reply' );

	wp_head();

No explicit inclusion of adminbar.css!

But, here’s what actually gets rendered in the browser:

<link rel="profile" href="http://gmpg.org/xfn/11&quot; />
<link rel="stylesheet" type="text/css" media="all" href="http://my-domain.amazonaws.com/wp-content/themes/my-foundation/style.css&quot; />
<link rel="pingback" href="http://my-domain.amazonaws.com/xmlrpc.php&quot; />
<link rel='stylesheet' id='bp-admin-bar-css'  href='http://my-domain.amazonaws.com/wp-content/themes/my-social/_inc/css/adminbar.css?ver=3.0.1&#039; type='text/css' media='all' />
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://my-domain.amazonaws.com/xmlrpc.php?rsd&quot; />

The unwanted link to adminbar.css has been injected.

I assume it must be something in wp-head() doing it – is there a hook to turn it off?

/buddypress/bp-core/bp-core-cssjs.php

follow up – it’s actually being added in the function:

bp_core_add_admin_bar_css()

in bp-core-cssjs.php

I can’t help but think this should be in the default theme, not in the core files.

@hnla – posting simultaneously !

It should be in the theme not in core files but it needs to load at ‘init’ ? or does it? is it that it must load before theme loads

ok… two solutions:

1. the nasty hacky – adding define (‘BP_DISABLE_ADMIN_BAR’, TRUE) in our theme’s functions.php

Why nasty hacky: well it inserts inline CSS into our footer to hide the adminbar and remove the padding; that’s nastiest enough in itself, but it also uses !important to override anything we actually want to do – even nastier.

2. the cleaner – adding remove_action( ‘init’, ‘bp_core_add_admin_bar_css’); in our theme’s functions.php

That does the job!

Unfortunately, we have to add that in the functions.php of any additional theme we want to use. Let’s get all this presentation stuff in the default theme where it belongs (not in the core)… I’ve said this a lot recently.

@rogercoathup

That nasty hack shouldn’t be an issue and it is not so much nasty as plain illegal to place style tags as children of ‘body’

This is the ticket I raised ages ago, well I and another but wasn’t aware it was a duplicate, the style rules never were required as the adminbar was removed and didn’t require any styles to help it along, the ticket was moved here there and everywhere, but I forced the issue by moving it back from 1.3 to 1.2.6 and requested that it be dealt with as it was a simple fix so in 1.2.6 those style tags don’t exist. previously I was having to use

remove_action(‘wp_footer’, ‘bp_core_override_adminbar_css’);

If I was hiding the adminbar for logged out view.

none of the solutions provided here solves the problem , not even editing the bp-core file as mentioned in the first post

any ideas ?

Possibly because there are is a mix of issues, if you referring to the remaining padding-top then that is a property being declared in default.css on the #header ruleset and will be there regardless of the state of the adminbar:

I have only time to suggest a quick fix for that in lieu of a new ticket raised on the overall issue for 1.3

You can try dropping this into a function.php file in a child theme (you will need to add opening php tag as your file structure dictates)

function cancel_header_padding_for_no_adminbar() {
   if(defined( 'BP_DISABLE_ADMIN_BAR' ) || $bp->doing_admin_bar = false) ?>

   <style type="text/css">/*<![CDATA[*/ #header {padding-top:0;} /*]]>*/ </style>
<?php
 }
add_action( 'wp_head', 'cancel_header_padding_for_no_adminbar' );

It would also probably work in bp-custom.php to ensure it was picked up for all possible bp themes.

Note: I do not suggest this as an answer it’s a hack to get around the issue, but not a good approach all in all

I don’t know may be I’m doing something wrong , this above solution is also not working for me .

Then you’re doing something wrong! Without actual detail on what you have done or tried to do it leaves it to us to have to makes guesses which generally is wasteful of time and resources.

Rather than simply state it didn’t work describe what you tried to do with the above code, also we have little detail on what setup you are running i.e custom theme etc