When using Admin menu (without overlay) the task buttons are hidden by the Admin menu.

My workaround is adding this to screen.css:

.admin-menu #tasks {
  top: 29px !important;
}

.admin-menu-with-shortcuts #tasks {
  top: 65px !important;
}

.adminimal-menu.menu-render-newline #tasks {
  top: 58px !important;
}
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wolfgang Reszel’s picture

Well, it's better to put the logic into the script.js so it's not dependent on the admin menu theme.

(function($) {

Drupal.stanley = Drupal.stanley || {};

// Stanley Behaviors
Drupal.behaviors.stanley = {};
Drupal.behaviors.stanley.attach = function(context) {
  // Taskbar
  Drupal.stanley.taskBar();

  // Table header offset
  Drupal.settings.tableHeaderOffset = 'Drupal.stanley.tableHeaderOffset';

  // Recalculate taskbar position on open/close toolbar drawer
  $('#toolbar a.toggle').bind('click', Drupal.stanley.taskBar);
}

// Taskbar
Drupal.stanley.taskBar = function() {
  var tasksHeight = $('#tasks').height();
  var toolbarHeight = $('#toolbar').height();
  $("#tasks").css('top', (toolbarHeight + $('#admin-menu').height()) + 'px');
  $("body").css('padding-top', tasksHeight + toolbarHeight + 'px');
}

// Table header offset
Drupal.stanley.tableHeaderOffset = function() {
  return $('#tasks').height() + $('#toolbar').height() + $('#admin-menu').height();
}


})(jQuery);
joelpittet’s picture

Status: Active » Needs work

@Wolfgang Reszel That seemed to do the trick though it only works well with "Adjust top margin" and " Keep menu at top of page"

Would it be better if it did this: $('#admin-menu').length > 0 before using it the height?

Thanks for the patch:)

joelpittet’s picture

Issue summary: View changes

Needs !important in some cases

autopoietic’s picture

There is a body class for admin-menu, can it not just go on that? It works alright for me anyway.

 body.admin-menu #tasks {
  margin-top: 20px;
 }

Love stanley for admin, its really solid.

joelpittet’s picture

Because position: fixed; doesn't care about position: relative context at all, it's kind of annoying. This causes issues with other toolbar replacements too like navbar or admin.

Maybe instead of dealing with it in JS or CSS you can deal with it with markup and a bit of CSS using an approach like this:
http://stackoverflow.com/a/11833892/80281

Then that position fixed will have a bit of a context of where it's supposed to be fixed to?

Not sure if it will solve all problems but may help.

basvanderheijden’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
615 bytes

I applied the following patch to 2.0-alpha3 to mitigate the issue.