The administration toolbar gets obscured by the administration menu if positioned on the top of the page.

CommentFileSizeAuthor
#7 play_nice_with_admin_menu.patch1010 bytesdnotes
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

MrKistic’s picture

Not a fix but a simple workaround for a tight deadline that I'm currently facing while using this module. Just load this JS snippet:

$(function() {
  // fix admin module menu layout if admin_menu present
  if ($('#admin-menu') && $('#admin-toolbar')) {
    $('#admin-toolbar').css('top', '20px');
  }
});

Only useful if you've got the admin toolbar positioned at the top, adjust the pixel value as required. I guess a similar module level check should probably go within the module.

forestmars’s picture

I'm actually seeing the opposite problem— enabling admin blows out admin_menu's toolbar.

This really wouldn't be much of of problem except that you now have duplicated functions on the admin bar (eg. modules -> list). In fact, it's really unclear what the point of the modules item is, since it only gives you list + uninstall which you already have under structure/site-building.

Moreover, where did the missing options —such as all of user management— go ?

yhahn’s picture

Status: Active » Closed (won't fix)

Not going to fix atm - I highly recommend you choose one module or the other, given that they have such similar functionality (but different approaches).

geerlingguy’s picture

Version: 6.x-2.0-alpha5 » 6.x-2.x-dev
Status: Closed (won't fix) » Active

I would really, really like to use both, though... could you possibly include some conditional check to see if admin_menu is working.

The thing is, admin_menu is so much nicer for scroll-through-click-done, whereas Admin is great for click click click click/drilling down. Not as quick, but more functional for some purposes...

nicholas.alipaz’s picture

I agree with op and others in that they should both be able to be used in conjunction. They do offer some of the same navigational functionality, but admin offers more than just it's navigational functionality in that it has the usefulness of blocks. Some may even prefer admin_menu's navigation and the use of admin for blocks, in this use-case admin should definitely adjust to admin_menu's position.

It should IMO be fairly trivial to detect admin_menu and then adjust the top margin of admin by 20px.

In the init() hook or wherever you are adding JS:

...
$settings = array(
  'admin' => array()
);
if (module_exists('admin_menu')) $settings['admin']['admin_menu'] = TRUE;
...
drupal_add_js($settings, 'setting');
...

Then in your JS add something like:

...
  var settings = Drupal.settings.admin;
  if (settings.admin_menu) {
    $('#admin-toolbar > .admin-toggle').css('margin-top', '20px');
    $('#admin-toolbar > .admin-blocks').css('top', '20px');
  }
...

This would leave a little 20px gap at the top if you have admin_menu set to stay at top of page and you scroll down, but I don't really mind it.

nicholas.alipaz’s picture

For those who want a simple module to do the job (this is completely untested, but should work):

admin_and_admin_menu_fix.info:

;Id: $
name = Admin and Admin Menu Fix
description = Fixes spacing issue between admin and admin menu.
core = 6.x
version = VERSION

admin_and_admin_menu_fix.module (don't include the closing php tag)

// Id: $
/**
 * Implementation of hook_init().
 *
 * Adding in some JS to handle having both admin_menu and admin module enabled.
 */
function admin_and_admin_menu_fix_init() {
  $settings = array(
    'admin_and_admin_menu_fix' => array()
  );
  if (module_exists('admin_menu')) $settings['admin_and_admin_menu_fix']['admin_menu'] = TRUE;
  drupal_add_js($settings, 'setting');
  drupal_add_js(drupal_get_path('module', 'admin_and_admin_menu_fix') . '/admin_and_admin_menu_fix.js');
}

admin_and_admin_menu_fix.js

// Id: $
Drupal.behaviors.admin_and_admin_menu_fix = function () {
  var settings = Drupal.settings.admin_and_admin_menu_fix;
  if (settings.admin_menu) {
    $('#admin-toolbar > .admin-toggle').css('margin-top', '20px');
    $('#admin-toolbar > .admin-blocks').css('top', '20px');
  }
}
dnotes’s picture

Status: Active » Needs review
FileSize
1010 bytes

CSS fixes the problem for me. Yhahn, I feel strongly that this is not simply a matter of different approaches; Admin module allows for fantastic functionality including addition of blocks and all sorts of other goodies to the administration of a page (your context editor is especially nice), but it fails in the UX requirements of actually accessing the administration menu - which is the only thing that admin_menu does well. Maybe if you had a clickless-interface to administration menu, I could think of giving admin_menu up. In the meantime, it really shouldn't be hard to have both. CSS-only patch attached works fine for me in all configurations on Firefox and in Chrome - I'm very sorry but I didn't test it in IE.

bibo’s picture

I'm using admin_menu and admin together on pretty much all my modern sites. There are many reasons why I do this, but mainly several admistator types:

- content managers see "admin" sidebar, which has only what they need (add nodes, maybe some info pages and lists etc)
- top admins see both admin and admin_menu, and have all administrations options available with one click.
(- anonymous users obvisouly see neither)

It works well, but I still need to add some CSS on each site to put the admin-sidebar 20 or 30 pixels apart from top. No Javascript needed for that, but I need to include the custom CSS via a module, because I use an admin theme (which is rubik btw, thanks yhahn for that as well).

They definitely should be useable together without manual customization, especially since this compatibility would be so easy to include in the module (maybe even with an on/off checkbox).

(+subscribe)

cluke009’s picture

Just tried out the module by nicholas.alipaz and it works like a charm. Just have to remember to have the sticky header enabled so it doesn't look goofy once you scroll.

Anybody know of a way to check for this?

dnotes’s picture

When I provided the CSS patch in #7, I thought it would be better than another module because... well, because it's just CSS. They basically do the same things. Is there a reason that the module approach is preferable?

nicholas.alipaz’s picture

@dnotes I am all for the css patch, just don't like patching a module if not necessary. For those who need a solution now and use a different admin theme than their main site, the module approach is likely best until something has been added to admin module to support this.

@cluke009, I am using it on my sites without the sticky header (I don't like that feature), and I don't mind the way the element "looks goofy". This is why I didn't make a check for it.

Fabianx’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: ++patch

+1

corbacho’s picture

+1

brunorios1’s picture

+1

dnotes’s picture

Fabianx, just to be clear, you tested the patch in #7?

Fabianx’s picture

Yes, I did. Sorry for not giving a more thorough review. I ended up adding the same code to our theme on the site using both modules.

dnotes’s picture

Wow, thanks. Hopefully this can get committed.

paskainos’s picture

I've used the two (Admin + Administration Menu) together on several sites for years, for many of the same reasons (mentioned by @bibo in #8 for instance) and have continued this practice into D7x >. All it takes to remedy this pesky nuisance is one line at the end of admin.toolbar.base.css:

D7
/**
 * Playing nice with admin menu
 **/
body.admin-menu div#admin-toolbar.vertical {
  top: 30px;
}
D6
/**
 * Playing nice with admin menu
 **/
body.admin-menu div#admin-toolbar.vertical {
  top: 21px;
}

That's it - voila! You're done.