Bug #471
closedAdmin bar covered by some themes
0%
Description
Some themes such as the one currently used by the CUNY Games Network
http://games.commons.gc.cuny.edu/
cover the admin bar.
Updated by Chris Stein over 13 years ago
My current suggestion is to add a 28px padding-top to the body element. For this to work it has to be done in a way that it won't be overwritten by other sheets. Boone suggests adding !important to it.
Updated by Chris Stein over 13 years ago
Boone also suggests possibility of loading style in footer element as another way to override other CSS
Updated by Boone Gorges over 13 years ago
Before anyone jumps on this, make sure to check the existing admin-bar stylesheet. It should be doing this already, so it'd be worth finding out why it's not.
Updated by Boone Gorges over 13 years ago
- Status changed from New to Assigned
- Target version set to 1.2
Updated by Ron Rennick over 13 years ago
@Boone - IIRC something in the theme was overriding the BP css. But, I agree, the best place to fix this for all the themes is in the admin bar CSS, if possible.
Updated by Matt Gold over 13 years ago
- Assignee changed from Chris Stein to scott voth
Updated by scott voth over 13 years ago
Can they just enter the following in Custom CSS?
#wrapper {
margin-top:28px;
}
I'm using the same theme and that seems to work for me.
Updated by Matt Gold over 13 years ago
Most themes don't allow members to customize CSS; Atahualpa is unusual in that respect. As Boone suggested above, it seems like we should adjust this in the BP Admin bar.
Updated by Daniel Bachhuber over 13 years ago
Hey all,
We had this same problem with themes on the J-School network a while back. Here's the solution I found: https://github.com/cunyjschool/CUNYJ-BuddyPress-AdminBar/blob/master/js/cunyj_buddypress_adminbar.js Feel free to poke around the plugin for other things we're doing.
Cheers,
Daniel
Updated by scott voth over 13 years ago
Looks great! Thanks Daniel - I will check it out.
Updated by scott voth over 13 years ago
Here’s what I found on this - the admin bar is rendered in the footer and positioned absolutely at the very top of the window. It inherits positioning from the wrapper div, or the container div of the theme, if it exists. So I found setting the wrapper’s top margin or padding doesn’t help.
One solution I found was to force everything down by setting the body’s “margin-top: 28px” – but this seems a little heavy-handed and affects all pages – while the problem is just for blog pages.
A better solution was to set the body’s “padding-top: 28px”. This seems to only impact blog pages – and is overridden on other pages, except on the wiki page.
This uncovered another problem with the admin bar’s z-index. I saw this on the “Games” blog – WooThemes seems to set their z-index for their navigation bars higher (“9998” and “9999”) than the admin bar’s current z-index (“1001”) – thus causing the admin bar content to get over-layed where the two intersect (z-index controls layering). I bumped up the admin bar’s z-index to “11001” and it fixed the issue.
So to recap: 2 little changes to admin_bar.css:
body {
padding-top: 28px;
}
And change #wp-admin-bar's z-index from 1001 to something over 9999.
I am new to this and am open for suggestions…
Updated by Matt Gold over 13 years ago
I'll let Boone speak to your proposed fixes, Scott, but I need to pause for a minute and note that before Boone was the big-time BuddyPress programmer he is today, he began work on the Commons by helping me with z-index issues on the Commons MediaWiki install. Which is to say that I'm feeling pretty optimistic about your potential growth as a developer!!! Keep up the good work and sleuthing.
Updated by Boone Gorges over 13 years ago
Scott, this sounds like a fine solution to me. Can you commit it and push it up to the master so I can have a look at it?
Updated by scott voth over 13 years ago
Hi Boone - Okay - think I pushed it up to the master correctly - but let me know if I did anything wrong. My first time...
Updated by Boone Gorges over 13 years ago
- Status changed from Assigned to Resolved
Looks nice from what I can see, Scott. Thanks!
Fixed in https://github.com/castiron/cac/commit/9d02716515d36a5b374b3f1c2231b2b004279a51