When the admin overlay is used, the top margin setup is not pushing the overlay down. It used to work fine on 7.x-3.0-rc1 but after upgrading to 7.x-3.x-dev it stopped working as expected. The overlay goes below admin menu instead of getting pushed down. I have attached the screenshots with differences.

Will there be fix for this or can anyone provide some suggestions on how to fix this?


new25.64 KB

I'm not sure if my issue is related, but I can't get rid of the standard D7 admin overlay, even though I disabled the core module for it and cleared all caches. So Admin Menu sits on top.

I have the exactly same problem as you! Did you find a solution?

Hi abuzakaria,
nice administration theme you have. I know this is some off-topic, but can you tell me with theme are you using for admin?
Thanks in advance.

Nuno, were you asking me? No I haven't found a solution :(

I asked you, because maybe you had found a solution! But unfortunately, no one of us, had found a solution yet.

Best regards

No problem. Oh, and I think I'm using the default admin theme, Bartik, or Seven.

Solution to issue posted by Steel Rat. Disable the Toolbar module and the second bar should disappear.

Status:Active» Fixed

I believe this is fixed in rc2.

Version:7.x-3.x-dev» 7.x-3.0-rc2
Status:Fixed» Active
new19.46 KB

I just upgraded from rc1 to rc2 and am now experiencing this issue.

Admin Menu overlay bug

Same as #9, using Rubik.
@ #3 It's Rubik.

While not a practical (or permanent) solution for everyone, adding top:30px to the #overlay style declaration in overlay-child.css works for the Rubik admin theme (Rubik overrides the css file in the core module folder).

Love the rc2 admin menu.

I can confirm this issue in both 7.x-3.0-rc2 and 7.x-3.x-dev with overlay. The admin theme doesn't seem to matter (tested seven and rubik).

#10 does solve the issue with the overlay but it seems it's actually an issue with admin_menu since toggling "adjust margin" doesn't seem to do anything even after clearing client/server cache.


+1, same issue with 7.x-3.0-rc2+7-dev, Bartik theme. If you have the shortcuts menu expanded, it covers everything.

Here is a patch to the admin_menu_toolbar css that fixes the overlay positioning problem.

Title:Top margin not working with OverlayOverlay appears behind the menu toolbar
Version:7.x-3.0-rc2» 7.x-3.x-dev
Status:Active» Fixed
new1.57 KB

Overlay has a built-in facility for that.

Thanks for reporting, reviewing, and testing! Committed attached patch to 3.x branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Hi @sun, your #14 patch went into rc-3 I see, however the problem persists for me and still requires the CSS fix I put in #13.

Status:Fixed» Needs work


Did you run update.php?

I can attest the patch in #14 is not applying to 7.x-3.x-dev. If its already been committed to dev then its not working.

Status:Needs work» Fixed

7.x-3.0-rc3 contains the patch here in #14 and fixes this issue.

Make sure you run update.php and clear all caches after updating.

Please reopen with more details if issues persist.

In reply to comment #3 - I used Rubik theme http://drupal.org/project/rubik

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:7.x-3.x-dev» 7.x-3.0-rc4
Status:Closed (fixed)» Needs work

I've had the same problem with -rc4, but sporadically. Every so often the top overlay will be beneath the admin menu, but when this occurs is very unpredictable.

Notifications are hidden beneath the admin menu too.

I've tried applying the patch from #14, but it appears as though some of these changes have been included in the -rc4 release.

Any help would be appreciated, thanks!

Version:7.x-3.0-rc4» 7.x-3.x-dev
new34.83 KB

I'll try to explain my theory about this issue. For the sake of clarity, I'll add another screenshot.

Admin Menu - Overlay(A) - Means opening a non-admin page (no overlay) and clicking an option in admin_menu (i.e. /admin/people), opens up the overlay correctly pushed down.

(B) - Is the consequence of refreshing (A) (i.e. press F5 with the overlay already open)

(C) - Is merely (B), but in the case of having an small output device (the problem with this is the entire titlebar covered by admin_menu, so the close button will be inaccessible - of course it depends on the theme)

At least for me the answer is behind the scenes. The real problem is the order of creation of #admin-menu and #overlay-container objects and the use of class "overlay-displace-top" as the overlay's reference of which object it should displace from. While doing (A), admin_menu is already present at the page (so "overlay-displace-top" class is already assigned to the root <div> element of admin_menu) and at the creation of the overlay, it can be used as the needed reference. While doing (B), for some unknown reason to me, the order is inverted; overlay is created first and there is no "overlay-displace-top" to take as reference, so the <body> element becomes the reference point (this is at the parent level). Also Firebugging this a little, shows the following simplified HTML, where only is relevant the creation order of #admin-menu and #overlay-container:


<html class="js overlay-open">
  <body class="html not-front no-sidebars admin-menu">
    <div class="region region-page-top">
    <div id="page">
    <div id="admin-menu" class="overlay-displace-top admin-menu-processed admin-menu-position-fixed">
    <div id="overlay-container">


<html class="js overlay-open">
  <body class="html not-front no-sidebars admin-menu">
    <div class="region region-page-top">
    <div id="page">
    <div id="overlay-container">
    <div id="admin-menu" class="overlay-displace-top admin-menu-processed admin-menu-position-fixed">

Javascript debugging also shows that in (A) there is a valid $('.overlay-displace-top'), which is not the case in (B).

Going further, I statically assigned the "overlay-displace-top" class to some element known to be there before the creation of the overlay (i.e. the <body>) and the result doing either (A) or (B) would be the creation of the overlay at the end of the page (probably only visible by scrolling down the page).

My question is if the creation order can be enforced. Or maybe a solution could be that overlay should "stick" as a sibling element to the element containing the "overlay-displace-X" class. Positioned after the element in case of "-top" and before the element in case of "-bottom".

Previous versions still work because they do several things in a different way.



I also have seen this issue with RC4

I noticed that the admin menu module wasn't adding the admin-menu class to the body. So I did something like this and it resolved my overlap issue.

* Implements theme_preprocess_html().
function admin_menu_toolbar_preprocess_html(&$vars) {
  if (user_access('access administration menu')) {
    $vars['classes_array'][] = 'admin-menu';