Stick Admin Bar To Bottom

Viewing 6 replies - 16 through 21 (of 21 total)
  • Thread Starter Larry Overton

    (@larryoverton)

    Everything seems to work in all of my themes but the one I use. So, whatever it takes! My theme is a new one not yet unglitched as yet…or possibly because I seen the need to customize part of the javascript to NOT work. I for one am not one to care what core file or anything else has to be changed as long as it suits my need. Al;ways a new file can be uploaded again at worst.

    Instead of changing core files (and trying to keep track of what needs to be changed or added or removed every time you upgrade), here’s a way to override any css you don’t like in the core files and in any plugins that add css:

    Create a css file called override.css and put it in the same directory as your theme’s style.css file. Fill it with any style declarations you need to override anything declared elsewhere.

    Then, in the functions.php file of your theme, add this code:

    <?php function stylesheet_override() { ?>

<link rel="stylesheet" id="overridecss"  href="<?php bloginfo('stylesheet_directory')?>/override.css" type="text/css" media="all" />

<?php
}
add_action('wp_head', 'stylesheet_override',20);
?>

    Add it after the existing closing ?> or else remove the first <?php and last ?> from the above code.

    The function is called by <?php wp_head(); ?>, so make sure your theme includes that in the <head> part of the header.php file.

    The number in the add_action arguments is the priority. The number 20 is used here to make sure the code is inserted after the other css in the <head>. If that’s still not high enough a number to make it show up last in the source code, just replace it with a higher number. Being listed last is what makes it override rather than be overridden.

    Actually, there are some simpler ways to override core and plugin css:

    Create the override css file as in my previous post, but instead of making a function for it in the functions.php file, link to it in your theme’s header.php directly, by adding this part of the code in-between <?php wp_head(); ?> and the closing </head> tag:

    <link rel="stylesheet" id="overridecss" href="<?php bloginfo('stylesheet_directory')?>/override.css" type="text/css" media="all" />

    OR:

    Make your override styles part of the theme’s style.css and then, in your theme’s header.php, find the line that calls the style.css file — usually something like this:
    <link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />
    — and move it to be in-between <?php wp_head(); ?> and the closing </head> tag.

    Of course, if you want to override something a certain way independently of the theme you use, it’s useful to have the function as a plugin instead of in a specific theme’s functions.php file or header.php file.

    In that case, you’d want the override.css file to be in the plugin’s directory, and the path to it would need to be changed accordingly, using plugin_url. Or you could do it the way Coen has, where the style declarations are included in the function itself and added to each page instead of linked as an external stylesheet. But I recommend linking.

    Either way, I recommend having the function triggered by wp_head instead of wp_footer, so that the output can be in the <head> section of the html instead of in the <body>. The way to make sure it overrides rather than is overridden is to include the priority number, as explained in my previous post.

    Of course, if you don’t know CSS, you’re dependent on someone who does no matter which way you choose to override. But I definitely agree with Coen that the styles introduced by the _admin_bar_bump_cb() function should be overridden rather than altering the wp-includes/admin-bar.php file.

    johngoold

    (@johngoold-1)

    I agree with what has been said about not altering core code.

    However, I do have an issue with what this thread is all about. Why on earth would someone put into the core code (apparently starting with WP 3.1.0) something that would break people’s themes? I just wasted an hour tracking this problem down and then confirming my diagnosis was correct by searching for and finding this thread.

    So, we use a workaround that is legitimate and doesn’t alter core code. Now, what happens when someone wakes up and either removes that style (which should never have shown in in first place) from the core code (or better yet, figures out how to make it conditional so it only shows up for the admin theme (or wherever it is actually needed)?

    My workaround won’t actually break, but I wouldn’t be surprised if the effect would be that some people lose 28px of the top of their page.

    Heartwood

    (@heartwood)

    I imagine the disregard for breaking older themes is probably related to the idea that all themes in the repository are required to be kept current with any core upgrades. I imagine all themes in there now are able to accommodate the admin bar, or they wouldn’t still be in the repository. When the admin bar was added and needed a spatial spot left open for it, I imagine the themes that didn’t already have the body code in a wrapper div had to have one added to keep the theme in the repository.

    Premium themes, which are not in the repository in the first place, would tend to be updated as well (at least for a few years after release), since you can’t very well sell something that’s not going to keep pace with what it’s meant to be used for.

    If you wanted to use a theme that’s no longer in the repository, the way to fix it to accommodate the admin bar would be to add a <div> tag right after the <body> tag (in the theme’s header.php file), and a </div> tag right before <?php wp_footer(); ?>, which in turn is right before the </body> tag (in the theme’s footer.php file). Putting everything but the admin bar into a wrapper div allows the added top-margin to push everything down while still keeping the same spatial relationships between the elements inside it, because for anything with an absolute positioning, it’s absolute in relation to its containing element rather than in relation to the body.

    johngoold

    (@johngoold-1)

    Ummm… I said “people’s themes”. I should have made it clear I was not referring to themes in the repository or purchased, commercial themes. I really did mean “people’s themes” — those individuals with their own web site who installed WordPress and created their own theme.

    I encountered the problem when working on a site using its own theme. It DOES NOT HAVE THE ADMIN BAR. It did, however, end up with 28px of background colour above the masthead (header, whatever).

    I fixed the problem using a variation of the original suggestion you made (thank you Heartwood, I appreciate your contributions). I’ll try your latest suggestion to see if that solves the problem in a cleaner way.

Viewing 6 replies - 16 through 21 (of 21 total)
  • The topic ‘Stick Admin Bar To Bottom’ is closed to new replies.