Duplicate administration menu rendering in Overlay child

which may explain why sun added a patch here: http://drupal.org/node/659488#comment-2431726 that passed

have you applied the patch?

A warning of any sort at this stage doesn't make sense. Unless the situation remains which I'd doubt.

I merely asked if you used the patch since it was not committed yet but passed. Thus the answer was no you hadn't but now you have and are faced with the same issue.

Whats to be confused about? I saw the patch and asked if you used it? You've responded and I've moved past it.

To me this issue seems like putting the cart before the horse with reference to reporting bugs against core with reference to a contrib module. Neither of which have been considered stable and are both only available for testing.

At this point are you sure it's not a bug in admin_menu 7.x-dev? rather than in overlay.module? Have you spoken with tha_sun to confirm the issue is with overlay.module and not with admin_menu?

Its a admin_menu issue + overlay issues where already is a patch for but that aren't reviewed/committed yet.

Thanks casey.

Therefore we can move this issue to that modules issue queue for Sun to take a look. If Sun confirms it's an overlay issue I'm sure he will move it back.

I'll chance getting scolded.

I'm not in a position to test -dev modules against -dev core. Sorry.

Based on casey's edit we can mark this as a duplicate. I wil update this thread with the link to patch thread as soon as I locate it.

Please reread caseys comment.

casey can you link to the patch/es you reference. Seems to me kaakuu would be the perfect person to test the patches already provided since he/she is already neck deep in trying to work with the two.

I'm not sure what patches apply to this issue. I've sorted the list specifically for overlay.module and patches but some of the issues are over my head.

I've had a look at admin_menu and this is totally a issue that belongs there. It doesn't contain any code to make it work with the overlay. It should at least use the 'overlay-displace-top' class to work properly.

Further it always adds its javascript to add the toolbar, without checking the page is opened in the overlay.

Besides that it is uses a fixed clickhandler so links on the menu_admin toolbar will never be handled/opened by the overlay.

I read something about clearing cache, so I thought this #649224: Cannot run certain batch processes (tests, update manager, etc) with the overlay enabled issue was related. But that's not even the case here.

Uh I ment #651086: Cache clearing is an ineffective mess in module_enable() and system_modules_submit().

based on #15 I'm moving back to admin_menu

Sorry Sun.

A better look told me that menu_admin actually doesn't use a clickhandler but doesn't apply behaviors to its @runtime added DOM structure (so still an admin_menu issue).

#668104: Make overlay respect other click handlers doesn't need that any more so that'll fix part of this issue.

@ #18 Understanding the way many modules mainatiners work, by witnessing them in both IRC and the issue queues (core or contrib) as well as recognizing the D7 promise to be ready when D7 is released on their project pages tells me they consistently grab the new -dev of core and test their own modules and tweak as needed when needed.

I have no doubt that Sun as well as other maintainers will ensure that their modules work with D7 when D7 is released. There is a concerted effort to do so on the part of many.

Therefore my testing of a module right now with so many outstanding core issues and patches wouldn't make life any easier for anyone and just clutter issues or issue queues and likely get many "bug reports" marked as duplicates. Especially where I can't provide a patch to help. I choose to create as little static as possible over issues that arise in any of the 2 -dev releases rolled every day. D7 isn't even at alpha yet. There is still some path to be walked with reference to core. Contrib has plenty of time to do their thing.

If I was a maintainer of a module, I wouldn't want to be checking my code every 12 hours to tweak my -dev module only to tweak it back as core continues to get worked on. I'd get most of the module ported, find the issues I'm likely to have then track those issues.

Personally, I test core in my local development machine when I'm bored or want to see the changes implemented since I installed last. When D7 core is ready and released as Beta or more likely RC, I'll test modules against core and report bugs I find at that time. Bugs today may not be bugs tomorrow.

Beyond that Sun has already stated that he's gotten admin_menu to work with the overlay.module in the issue previously linked to and that it may provide backports to fix admin_menu for D6, if I understand his comment correctly.

Just installed 7.0-dev with download via drush. Installed using option for preconfigured modules. Decided I could not operate with new admin system and installed Admin menu. It would not display, cleared cache, checked permissions, looked to see if it was a configuration issue. Found this issue, disabled Overlay and hey presto Admin menu works.

However the top "admin menu type" menu (edit) Toolbar is now hidden under the Admin menu.

Edit: I guess disabling that Toolbar solves that other issue.

Sorry guys. I have zero interest in supporting Overlay module. My patch for Drupal core actually disabled it by default.

I starred on its code for minutes, quickly tried to resemble what Toolbar module is roughly doing, but to no avail. If someone else wants to work on it, be my guest.

To make it work, it needs to work with disabled caching first. To disable admin_menu's caching, open your settings.php and insert the following at the end:

$conf['admin_menu_cache_server'] = 0;
$conf['admin_menu_cache_client'] = 0;

When that works, you can comment out those lines and prevent the client-side caching from running in the Overlay.

Non-working patch attached.

I'm not sure if I understand this issue, as it seems to have come a long way, mixing up overlay, the toolbar and whatnot ;)

Basically, what I was looking for, was to prevent admin menu from rendering again in the overlay. This is as easy as adding an overlay_get_mode() check in hook_init, to determine if the current page is to be rendered in the overlay vs. a regular page (the same check seems to also be missing in core's toolbar.module, but that's another issue).

So here is my solution to that.

AFAICS, Toolbar uses a different approach, based on some weird theme region hacks via hook_system_info_alter():

http://api.drupal.org/api/function/overlay_system_info_alter/7
http://api.drupal.org/api/function/toolbar_system_info_alter/7

My previous patch was an attempt to implement it in the same way, but TBH, I didn't completely understand those theme region hacks yet.

AFAIK (some more wild guessing) the overlay supports updating regions outside of itself, for example after adding a new content type the toolbar needs a refresh. hook_system_info_alter is used to tell the overlay in what regions to look for updated content. I was simply irritated by the doubled display inside and outside of the overlay, and whether this is a bug or not (it looks wrong at least).

I really don't know if this helps at all, but to at least temporarily disable admin menu in the overlay, I found pasting: "module_invoke('admin_menu', 'suppress');" after line 78 (if $custom_theme != $admin_theme ) in the overlay.module seemed to make everything work. I then added padding-top: 100px to #overlay-wrapper to bring the overlay down, then everything seems to work great. Knowing this I don't believe it should be too hard to create an override in the template file.

Hope this helps!

subscribe

Since admin menu is already supressing its own display on AJAX requests, couldn't we just use this same methodology to suppress page requests for an overlay? Seems like adding this at the top of admin_menu_init is an easy way to do it.

function admin_menu_init() {

  // Skip pages rendered in an overlay, prevent the toolbar from rendering with admin_menu_supress();
  if (strpos($_SERVER['QUERY_STRING'], 'render=overlay')) {
    admin_menu_suppress();
    return;
  };

Or, this code could be broken down and duplicated between the admin_menu and admin_menu_toolbar modules if you weren't worried about DRY and wanted to limit the overhead of calling admin_menu_supress -

	if (!user_access('access administration menu') || admin_menu_suppress(FALSE)) {
	  return;
	}	

	// Performance: Skip this entirely for AJAX requests or overlays.
	if (strpos($_GET['q'], 'js/') === 0 || strpos($_SERVER['QUERY_STRING'], 'render=overlay')) {
	  return;
	}

As of Drupal 7 alpha 6, I have no issues with the solution I posted above. This seems to be the cleanest and simplest way to deal with the issue in the admin_menu module. Update the lines in "admin_menu.module" and "admin_menu_toolbar.module" that are disabling admin_menu on ajax requests to also disable the menu in an overlay:

// Performance: Skip this entirely for AJAX requests or overlays.
if (strpos($_GET['q'], 'js/') === 0 || strpos($_SERVER['QUERY_STRING'], 'render=overlay')) {
  return;
}

I'm not able to reproduce this issue anymore.

Using last admin_menu dev version on Drupal 7.2, I can still see the admin bar is rendered a second time inside the iFrame. Using Firebug, I can see the admin_menu bar is once inside the iFrame, and once in the parent page (the last one getting over the other).
Isn't this what the issue was all about ?

At least, if we keep the two bars, it would be better if the one we can see is the one in the overlay, so that the active trail means something...

You'll find a commented screenshot attached. :)

I was have this issue today.

Running Drupal 7.7
Admin Menu 7.x 3.0 rc1

The double drop down bar was annoying. Until a fix is implemented, I decided to remove the menu from the overlay iframe with css. Since the admin menu has a higher z-index, the admin menu on the page will apear above the overlay iframe.

My CSS

.overlay #admin-menu {
display:none;
}

Hope this helps people that come here looking for a fix.

See also #1025846: [PATCH] Duplicate admin menu dropdown when Overlay enabled.

Similar to @smk-ka's #23, but actually setting admin_menu_suppress()'s static to prevent any further invocations down the line.

D7.12 and Admin Menu 7.x-3.0-rc1. I had the same problem and I had initially used patch #10 from #1025846: [PATCH] Duplicate admin menu dropdown when Overlay enabled which resolved the issue, but that issue was marked duplicate of this one. So, I have tested #34 here and this resolved the issue too, thanks. Should we move forward with this one then?

D7.12 and Admin Menu 7.x-3.0-rc1. As per my previous post #35, patch #10 from #1025846: [PATCH] Duplicate admin menu dropdown when Overlay enabled had resolved the issue. However, I then tested #34 here as the other one was closed as duplicate. This seemed to be working ok as now the duplicate menu is removed, but I just realised that when this patch is applied the "Adjust top margin" setting in the Admin Menu settings is not working, so even when it is checked the top margin is not adjusted, resulting in content being hidden from the Admin Menu toolbar. This works correctly with the patch from the other issue.

Can you please check? Thank you.

I've just committed #502408: Move invocation/processing into hook_page_build()

Can you check whether this issue still exists with the latest code?

I have this issue with last admin_menu version (7.x-3.0-rc1). It is easier to see if you have different theme for the administration and the font-size is different as well.
The patch in #34 works for me.

#502408: Move invocation/processing into hook_page_build() fixed this issue.