it’s simply added to the footer area for what I would guess are perceived as seo concerns keeping it towards the end of the document and using poss abs to visually render it at top of page. There is nothing stopping you changing the add_action(‘wp_footer’, ‘bp_core_admin’) but I think that you need to do this in a functions file in a child theme if using one, you will need to remove the default action then ad a new one, that way your changes will be preserved. I would have thought you could add it to the do_action(‘bp_header’) hook that sits at the end of the div#header.
Thanks much hnla. I’ll look into your suggestions in more detail. For the time being I think I may keep edits simple and just change #wp-admin-bar .padder css from position: fixed to position: relative and style accordingly. (#wp-admin-bar would stil be absolutely positioned). I don’t want to add up a can of worms by editing too much. Was wondering if it was more modular than editing functions etc — ie, just dropping in a hook into the header — but perhaps not…
Thanks for your reply!
The reason that the admin bar is loaded in the footer might be partially for SEO reasons, as @hnla hypothesizes, but I’m guessing it’s more for plain old load time while it’s a minor annoyance if the admin bar takes an extra second or two to show up, it’s a real problem if the content of the page is delayed. Putting this kind of stuff in a footer is, I think, pretty standard practice. @mrsalty If you want to move the code higher up in the document for some reason, put the following into your theme’s functions.php file:
remove_action( 'wp_footer', 'bp_core_admin_bar', 8 );
add_action( 'bp_head', 'bp_core_admin_bar' );
If all you want to do is to have the admin bar stay at the top of the page instead of sticking to the top of the browser window as you scroll, just set its positioning to absolute rather than fixed:
#wp-admin-bar { position: absolute !important; }
Yeah, my sense is that it isn’t calling anything sql/db intensive: just a handful of static links. But because it is a plugin (originally, yes?) maybe there are some performance issues? And/or:
Here is what I think: admin-bar was originally a plug-n-play plugin that didn’t require all the thousands of themes to be reconfigured just to use it so it was decided to make it something that sits on top via absolute positioning — and for fun: can scroll with the page via position:fixed. And so, for proper placement letting most of the page load first before positioning the div offered the best performance?
I agree with you both: my goal was to make it relative and inline for simplicity’s sake — but the opposite is probably true because of this architecture: would be further from default structure and could have some performance issues.
Thanks for the help!
Ah hadn’t considered load times as Boone points out, although I don’t really see that there would be a huge issue there and there are many more things going on that do cause page content rendering issues. When I see document elements flowed in this way and visually re-ordered it tends to be from a somewhat misguided belief that it benefits anything even though the supposed benefits have never been proved in any testing and somewhat disproved from an accessibility point of view. In light of this elements purpose I would actually tend to think it’s best placed as it is, if I were designing a theme from scratch I would probably go along with it’s positioning in the footer area, but… one does need to consider text rendering and assistive devices if this element and it’s links are important then where do they fall in the document flow when the page is read by screen readers or rendered sans styles plain text, these are considerations all too often overlooked.
One thing to consider though is how IE6 handles things or not as the case may be, position :fixed is not understood by IE6 look at the default theme in that browser!
If staying with position:fixed then do add rules for IE6 overridding fixed with absolute using Conditional Comment stylesheets targeted for IE6 or lte IE 7 and use star selector filters for any IE6 specific rules. IE6 sadly is not quite as dead as many would love to believe and many companies and organizations are still using it and not able or willing to upgrade.
@hnla yes, for accessibility reasons it makes sense… re: ie6, i agree. which is why i favor the simplest structure… everything inline and relative. Makes for more consistency cross-browsers and less ie hacks required.
