Admin menu disappears (randomly), needs either cache to be emptied on every page or page refresh several times

I have the same problem and can confirm it. The problem also appears if the caching mode is disabled.

Have you try the Wipe and Rebuild ? In the admin_menu administration ? (admin/settings/admin_menu)

Best regards,

SL

I'm sorry, but I can't find this option under admin/settings/admin_menu.

Please try again with the latest development snapshot.

Well, I already tried the latest version from April the 26th.

same here, tried the latest dev and drupal.

Event after I ran
TRUNCATE `cache` ;

TRUNCATE `cache_admin_menu` ;

TRUNCATE `cache_block` ;

TRUNCATE `cache_content` ;

TRUNCATE `cache_filter` ;

TRUNCATE `cache_form` ;

TRUNCATE `cache_menu` ;

TRUNCATE `cache_page` ;

TRUNCATE `cache_update` ;

TRUNCATE `cache_views`

Full uninstall of the module

-------------------
I have seen this before with this module.
In this case and the others it happened during a drupal version upgrade like a security patch etc.

Drupal 6.11, fresh dev version of the module, basically empty site. No menu. Appeared once, then vanished, never to be seen again.

I have the cache router module installed; however, the cache is created normally. Deleting the cache items brings the menu back for one page load.

Updating to critical. Module is useless without a fix.

subscribe *sigh*

Cross-referencing potentially duplicate issues:

#442560: Admin menu disappears (randomly), needs either cache to be emptied on every page or page refresh several times
#431202: Identical cache $cid incompatible with CacheRouter
#424960: Latest cache updates result in scrambled output

Please have a look at each one of them; reconsider whether anything in any follow-up might give you a clue, and report back your findings (in the corresponding issue).

Additionally:

1) Do you have JavaScript enabled?

2) Do you get any JavaScript errors?

3) Do you get a "ok-looking" raw HTML output when accessing the cache URL directly? (i.e. http://example.com/js/admin_menu/cache/98ho3inf2p1qwrf...)

4) Is Drupal installed in a sub-directory? Any other potential specials on your host/server?

Sorry, without further information this issue can only be marked as won't fix.

Feel free to re-open this issue if you want to provide further information. Thanks.

I had the same symptoms on my wamp on a module I was developing. Turned out a wrong coding (unix) had sneaked into my .info file. No other symptoms, just the disappearing Admin menu. Converted to utf8, everything was fine again.

edit: nope, wasn't that simple...

edit2: this has been really hard to test because the behavior in my case was not consistent, sometimes after enabling the menu would work and sometimes not. I couldn't identify any pattern.

sun wrote: "Do you get a "ok-looking" raw HTML output when accessing the cache URL directly?"
No I didn't. When I couldn't see the menu, that cache thing, viewed with Firebug, was also empty.

Now, my unfortunate module caused some (consistent) layout problems in IE6 and IE7. I finally narrowed the problem down to the BOM in the beginning of files. Ripped the BOMs off, and the site is now working consistently beautifully. I'm using Ultra Edit and I never really understood how all those settings were supposed to be. This page was very helpful:
http://www.ultraedit.com/forums/viewtopic.php?t=34

Now, what about that Admin menu? Like I said, the behaviour earlier was random, but at least for now I haven't got it not to work!

So please check your BOMs everyone. In all files that output something to the screen, I guess.

Thanks. I'm a... learner.

Had the same issue but I reverted back to 6.x-1.5 and all is well... :/

also before i reverted the wipe and rebuild option was gone from the settings page.

The problem is still here with the latest 6.x-3.x-dev. Nothing has been fixed.

I am happy to provide here what I found so far. The problem only happens with a new site I just set up. A few older sites are OK.

So, I added a few dpm calls to figure out when admin_menu_cache_set and admin_menu_cache_get are called.

Turns out ALL older sites have been (for whatever reason) calling admin_menu_cache_set and rebuilding menu on every page load.

The new site goes only to admin_menu_cache_get, fetches cid and hash and outputs settings Javascript like this:

<script type="text/javascript"> 
<!--//--><![CDATA[//><!--
jQuery.extend(Drupal.settings, { "basePath": "/", "admin_menu": { "destination": "destination=admin%2Fsettings%2Fadmin", "hash": "8dc920cf1ae263dc690ff84f21c7dbd5", "basePath": "/admin_menu", "replacements": { ".admin-menu-users a": "0 / 1" }, "margin_top": 1 } });
//--><!]]>
</script> 

Still for some reason this JS does not render the menu. I am not sure how/where it is supposed to fetch it, but surely it does not do it. However if I clear the cache, admin_menu_cache_set is called, menu returns, BUT disappears again on another page reload.

I found that admin_menu_js_cache never gets called, so probably it is possible that JavaScript for some reason gets broken. Given how many modules and themes could be causing a conflict, I am not that interested in debugging this mess.

We need an option to turn off client-side caching and/or find a real fix to infinite number of JS conflicts...

P.S. To fix the problem in the interim, I just commented out JS caching option in admin_menu_output that gets called here:

  if (!empty($_COOKIE['has_js']) && strpos($_GET['q'], 'js/admin_menu/cache') !== 0) {
    if (admin_menu_cache_get($cid)) {
      return;
    }
  }

If admin_menu_js_cache() is never called, then this can have two reasons:

1) The JavaScript never invokes example.com/js/admin_menu/cache - please enable Firebug's console and double-check whether you see a HTTP request there upon page load.

2) The js/admin_menu/cache IS requested, but admin_menu_js_cache() returned no or invalid data. Your browser will cache the contents of the HTTP request, regardless of what has been returned - please check whether clearing the cache of your browser changes anything.

Since I am still not able to replicate this bug, it would be great to get further debugging information about aforementioned possibilities.

If you cannot help in debugging and you need a quick fix, then just append the following to the end of your settings.php:

$conf['admin_menu_cache_client'] = FALSE;

I found the module that was breaking JavaScript, it was Feedback. It also broke collapsible fieldsets, but when I disabled it all JS problems went away.

Thanks for the settings.php solution. I think this problem simply needs to be prominently documented, since broken JS is a very common situation, especially for admins / developers who might be playing with unstable site configurations. Maybe JS caching should be OFF by default...

Hmmm! funny thing...

I started my own theme from scratch. Nothing fancy, not many modules enabled... in fact only those needed for clean URLs and nice paths + multilanguage support. I use D6.16 and all my modules are latest dev versions (If required I can list them + their respective versions). PHP, apache2 and MySQL to their latest versions as well. Memory set to 256mb. No caching or performance tweaks enabled whatsoever.

My theme has no css defined yet and it simply prints , , , $head, $styles, $scripts (even if empty for now) and all my $regions from the .info file. Also $logo, $site_name, $site_slogan, $help, $messages, $title, $content and finally $closure. As I said nothing fancy, simply a starter with all the above placed in some divs.

Now, to the issue...

The menu seems to disappear only on certain pages like say the Status report and /admin/menu while displays ok on others. Refreshing the page or clearing all caches doesn't seem to help. Generally it only disappears on some of the pages while on most displays ok. If I enable the settings.php option from post #15 the menu is shown in the pages that it didn't before but doesn't respect the 20pixels offset ('Adjust top margin' checkbox) on them while the offset and the drop-shadow effect work on the pages that used to work without the admin_menu_cache_client set to FALSE.

More troubleshooting showed that when I disable the Administration menu Toolbar style, then the issue goes away completely. So, I guess it only occurs when this submodule is enabled.

I will keep troubleshooting this (I'll disable not needed modules) and I'll post back here any extra findings.

It turns out that there is no need to clear cache (I use no optimization on the site). A simple refresh of the page brings the menu back.

Still... this is annoying!

@klonos: Your particular issue might be your web browser's caching settings. It sounds like your web browser might be caching the page except when you force a refresh. Here's a good tutorial on how to change those settings in Internet Explorer and FireFox: http://www.imasuper.com/53/technology/firefox-caching-get-latest-page-ev...

@Linxor: I did change that setting in all my firefox profiles and emptied cache. Restarting my workstation and also trying on other pc didn't help either. Thanx for bringing this to my attention anyways.

So, still the issue remains.

I can confirm this.

In my case it was caused by securepages.

As a solution try adding 'js/*' to the 'Ignore pages' section on admin/build/securepages.

.
I have securepages enabled for admin/* pages. So when an admin page is viewed the request for the admin_menu cache is sent out to https://sitename.com/js/admin_menu/cache/...
The problems arrises due to the fact that that url returns a blank 302 found page with location set to http://sitename.com/js/admin_menu/cache/..., i.e. a redirect to the non https version of the page. The browser doesn't follow that in the ajax request and uses the blank response as the contents of the admin_menu.

So is there a way to make the ajax request follow the location on the 302?
Or more straight forward: add some prominent documetation for caching to play nice with securepages 'js/*' must be added as an exception?

Edit: corrected js path in previous comment.

I ran into the same problem with 6.x-3.x-alpha4. Wasn't an issue in 1.5. Fenstrat's solution solved it for me.

subscribing

@adamo & fenstrat: you both seem to be using the securepages module(?) but I don't and I still have this issue. So, people any other ideas what else might be causing this?

@knonos: Another module that does redirections might cause similar behavior. You could take a dev copy of your site and start disabling modules until the problem goes away, then re-enable them until the problem comes back to find where the problem is.

I am on a production environment right now and cannot perform any tests (no time either due to deadline on going live). I promise I'll do that though, but cannot promise when.

...just title correction so its easier for people to find the issue.

subscribe

subscribing

subscribe

quick fix #15 worked for me, thanks Daniel...

I'm having this in a fresh D6.17 setup with only minimal module installation (i18n, views3, cck3, poormanscron - all in their latest dev versions). So I think we should give it a bit more attention...

@sun #15: I want to help troubleshoot this one and I do have firebug installed, but I need more detailed instructions on what to monitor (which firebug tab and any special firebug settings perhaps?) and how (I mean do I do it with just a single page reload?)

Here's what I see in the 'Console' tab in firebug when the admin menu finally loads:

http://my.site.net/en/js/admin_menu/cache/c3112e8baecb192e76cadc16bbe9ad0c 200 OK 609ms

I see nothing if the menu is not loaded. Where would I see any errors or warnings?

#15 worked for me as well. Strange. i wonder if that php entry will mess anything up when the module gets out of the alpha stage...

#15 does not working, This is still an issue :(

@kylebrowning Are you using the securepages module? If so try the solution in #21

The securepages module was also causing this to happen for me. Per #21 I added js/* to securepages ignore list and all is back to normal now.

Thanks for the tip,
Jeremy Zerr

I am not using Secure Pages myself, but a lot of people seem to confirm the issue and the resolution of adding js/* to the module's ignore list. Is this a solid solution? Does it pose any security risks? If 'yes' in the 1st question and 'no' for the 2nd, then I think we should post this as a known issue in both modules' front pages and documentation.

- edit to correct a closing tag. I hate that drupal.org doesn't use even the simplest of a WYSIWYG editor for posts :/ -

Also tried */js/* in Ignore List is it's working great so far.
Is there any situation where we wouldn't want */js/* in the ignore list?

I'm using Secure Site and I've the same problem. After first log in, it doesn't show up. After refresh, it does works.
Related: #876990: always needs a refresh

I too have been having this issue. Once I turned off cache css in my Boost module, the admin_menu appears in all pages.

However, while this fixes the problem of the admin_menu appearing, it does not cache my site's css files. Not the biggest issue in the world, I can live with it. But I would like the feature to work to assist in performance.

I ran into this today after upgrading Drupal core to 6.20. The fix in #15 solved the problem, though. I am not using the SecurePages module.

i'm facing this problem after upgrading to Drupal 6.20.
but #15 solve my problem.

Problem started for me after installing Aquia Slate theme and required modules on Drupal 6.20. Was running fine till I installed the skinr module. #15 solved it. Thanks

I started having this today with 7.x-3.x after I updated two test installations (one mysql and one postgresgl) to today's D7 dev (31-Dec-2010). I've never had this issue in D7 before. Now, it seems even harder to get the menu back (refreshing the page multiple times - with browser cache disabled + clearing drupal caches doesn't seem to help at all).

edit: ...scratch that - my bad.

subscribe

I have the same issue. #15 worked to fix it but I am concerned of what the ramifications of this are. The problem also seems to have arisen after upgrading to Drupal 6.20.

drupal 7, admin_menu dev.

after flush cache, admin menu appears once. After that, it dissapear.

in firebug,

GET http://u3220.****/js/admin_menu/cache/27c08d8c4dcb2159b2dfb6e6cc334027 200 OK933ms

fails to load this file.

I am using securepages. The admin_menu (7.x-3.0-rc1) is not showing on https pages without clearing cache. It shows for a single page but disappears on the next /admin/* page, until the cache is cleared, etc.

I have set Drupal core mixed session handling as in http://drupal.org/node/1037542#comment-3994888, and added */js/* to the ignore list as in #39. These did not help.

Update on #50. The problem still exists with admin_menu-7.x-3.x-dev.

Also having this problem in 7.x. Subscribing.

Subscribe. I have the same problem.

Steps to reproduce:
Clean install of D7.0, standard profile.
Download admin menu - 7.x-3.x-dev - 2011-Jan-30
Enable Administration menu & Administration menu Toolbar style.
Disable Toolbar (core module).
Navigate to homepage.

Admin menu behaves sporadically.
Core Toolbar sometimes stays, even though it is disabled. Once it disappears, it seems gone for good.
Admin menu randomly appears & disappears, especially on the home page.

Environment:
Local Acquia Drupal Stack
PHP 5.2.14 (more information)
PHP extensions Enabled
PHP memory limit 128M
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Update notifications Enabled
Upload progress Enabled (PECL uploadprogress)
Web server Apache/2.2.17 (Win32) PHP/5.2.14

Browser:
FireFox 3.6.13

Subscribe. Same problem here.

Environment:
- XAMPP for Windows v1.7.3
- Drupal 7.0
- MySQL 5.1.41
- PHP v5.3.1

I have set up a simplistic development environment and am able to recreate the disappearing admin menu trick whenever I enable a module that I am writing. The problem is, the module is nothing more than a single menu call back. I tried using a different text editor to ensure that file was encoded correctly. No dice.

Watching this thread with bated breath....

Subscribe

I noticed that if I turn on "Aggregate JavaScript files" in the Performance section, the bar completely disappears and I cannot get it back.

Using Secure Pages 6.x-1.9 and Secure Pages Hijack Prevention 6.x-1.6 here and #21 works for me. I added js and js/* and the issue seems to be solved (or worked around). Even with "Optimize JavaScript files" in the Performance section enabled.

The same problem in 7.x-3.x-dev. Admin menu appears after refreshing page. I don't need to flush caches

The same problem with the drop down menu is there when I use crome and a long list for views (plese see the pic) but not dropdown when I used internet explore
I have a local host enviroment with wamp server 5.3 php

This issue should be critical.

Subscribing...

I think I can help reconstruating this problem - it seems that the bar is disappearing when enabling database logging OR syslog OR in general reports ... can someone test this too?

Will test this later again...

I managed to get it working by commenting following lines from admin_menu.module in function admin_menu_js_cache:

header('Content-Encoding: ' . $encoding);
$content = gzencode($content, 9, FORCE_GZIP);

Even though headers seemed to be ok when checking with firebug it still gave this error when accessing /js/admin_menu/cache/664373b6e59cc0e04106b045cbb42d61:

Content Encoding Error
      The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

Headers with above lines commented out:

Response Headers
Date	Thu, 31 Mar 2011 12:53:25 GMT
Server	Apache/2.2.14 (Ubuntu)
X-Powered-By	PHP/5.3.2-1ubuntu4.5
Expires	Fri, 30 Mar 2012 12:53:25 +0000
Last-Modified	Thu, 31 Mar 2011 12:53:25 +0000
Cache-Control	max-age=1333112005
Etag	"1301576005"
Vary	Accept-Encoding
Content-Encoding	gzip
Content-Length	5885
Keep-Alive	timeout=15, max=98
Connection	Keep-Alive
Content-Type	text/html

Headers without commenting the lines:

Response Headers
Date	Thu, 31 Mar 2011 13:01:46 GMT
Server	Apache/2.2.14 (Ubuntu)
X-Powered-By	PHP/5.3.2-1ubuntu4.5
Expires	Fri, 30 Mar 2012 13:01:46 +0000
Last-Modified	Thu, 31 Mar 2011 13:01:46 +0000
Cache-Control	max-age=1333112506
Etag	"1301576506"
Vary	Accept-Encoding
Content-Encoding	gzip
Content-Length	5859
Keep-Alive	timeout=15, max=98
Connection	Keep-Alive
Content-Type	text/html

On Drupal 6 websites, I've seen this problem occasionally. But with the Drupal 7 version, I see it much more frequently, in both browsers tested (Firefox 3.6.16 and Chrome 10.0). Refreshing the page repeatedly does not solve the problem. Nor does emptying all of the cache tables. Nor does adding the $conf['admin_menu_cache_client'] code to settings.php, as instructed in comment #15.

In the JavaScript error console in Firefox, there are some errors that may or may not be related or helpful in debugging:

• Error in parsing value for "filter". Declaration dropped. In source file .../sites/all/modules/admin_menu/admin_menu.css?lj7pef, on lines 96 and 101.
• Error in parsing value for "cursor". Declaration dropped. In source file .../sites/all/modules/admin_menu/admin_menu.css?lj7pef, on line 206.

Fortunately, the temporary solution in comment #61 seems to be working.

My admin menu disappears too... In my case it happened after installing "User points Nodes and Comments" module.

I'm using Drupal 7, 7.x-3.0-rc1 version of "Aministration menu".

Help please.

This happens to too many people, changing priority.

I never noticed that before, but yes, it does seem to be tied to the enabling of Userpoints Nodes & Comments.

For me, it appears that the admin menu only disappears when the option "Aggregate JavaScript files." is enabled at admin/config/development/performance.

Hope this helps somebody.

I am using Secure Pages with the extra Toolbar Style module and #66 worked for a second - I disabled JS Optimization and flushed the cache, and the toolbar reappears, but it disappears after a few page loads. The Admin Menu Toolbar Style is working fine on non-secure http:// URLs. If I just disable the Toolbar Style, the admin menu seems to work just fine :)

Comment to #66 : I have this option (Aggregate JavaScript files) disabled... and still my admin menu disappears.

#61 fixed my problem. I'm having the same issue in D7 with admin menu randomly disappearing. Flushing caches fixes it most of the time but then it's gone right after that. It was working flawlessly for a couple months until today, but I can't think of anything that I've done that would have caused it.

Hi, #61 fixed my problem in D7, too.

I said disabling Toolbar worked for me in #63, I've since switched back to 6.x-1.5 because it was still disappearing sometimes, though not as often

confirms 63 and 65, i disabled userpoints nodes and comments and the admin menu re-appeared on my d7 setup

If this may help some of you guys here is what I experienced recently:
A couple of days ago my admin menu started to disappear and reappear some time (rarely) and it made me really go nuts...
I discovered that it was linked with the fact that I changed some php in a module and there was a blank line next to the <'/php'> tag. Since I corrected this e.g. I simply deleted the blank line everything is fine again. Weird but true! :)

I was able to reproduce this bug in Drupal 7 with Firefox 3.6/Win7 (64bit), on Debian, Apache/2.2.9 PHP/5.2.6. Turns out the cache request wasn't executed due to the defer attribute.

Committed attached patch.

However, looks like this particular change won't fix it for everyone who followed up here. Special thanks to @Tharna for providing some more clues. It's perfectly possible that default HTTP headers in D7 have changed and that we need to compare and adapt the code in admin_menu_js_cache() with Drupal core's bootstrap code.

This issue here has been "fluctuating" between 6.x and 7.x for quite some time now and I doubt the above patch will ever lead to a RTBC -> fixed state (even you Daniel seem to admit/predict this fact). Committing it was the right thing to do (seems pretty straight-forward) so people here can try the latest dev -which will include it- and have them report back. One thing though: was it committed to both branches?

The commit was made to master (7.x branch). I've tested it in d7 and now, admin_menu does not disappear.

Thanx for taking the time to answer my question Jaime and for reporting back with your results. I myself haven't faced the issue for some time now (mostly in D6 setups), but I fear that it is the kind of thing that will come back to bite me at some point.

Thought I'd throw my 2c in here — tried the very latest dev (7.x-3.x-dev, 2011-May-06) with no improvement. I finally traced it to a rogue space character BEFORE the <?php in one of our custom modules. Thought this info might help someone else.

confirms 63, 65 and 72.

Something in user points nodes and comments breaks it all.

I have erased the space character BEFORE the <?php in

/public_html/sites/all/modules/userpoints_nc/userpoints_nc.module

It seems to be working by now but who knows...

Good luck and thanks to all of you.

...did any of you guys using userpoints_nc file an issue for that rogue space then?

For me the problem is when secure pages is enabled. I can still use the site in HTTPS but when I enable the secure pages module the admin menu breaks.

With a fresh version of 6.x-3.x-dev on Drupal 6.20, I was seeing the menu disappear after showing one time.

I turned off page compression, and it started showing, which seems related to the observations in #61...

Turning off Page Compression fixes it for me too, 6.x-3. No idea what's causing it, it started when I tried using the Labjs module but it kept happening after labjs was uninstalled.

Hi, I was having the same trouble with admin_menu disappearing in my custom theme for D7.
Interestingly the #12 comment was my solution. I just converted my theme files to UTF-8 NO-BOM and my admin_menu is showing in all pages again.

I just converted "template.php" and all template files "NAME.tpl.php" from my theme. Hope this helps :)

Had the same problem with a custom theme. When i put back the print $page_top; on my html.tpl.php the menu came back, did not know it was print there (not sure yet...) Hope it helps someone

#61 worked,for me - D7 - only problem from this is that now "Keep menu at top of page" is on always

#84 & #85 did not fix anything (tried these before #61)

I had this "disappearing admin menu" issue whenever I enabled views_filters_selective sub-module in views_hacks 7.x-1.x branch, revision 4f21dbc5e8aefe25e4fab05dd4550f01f26278d2

admin_menu would disappear after enabling the module. Clearing the cache would make admin_menu reappear, but only for a single page load.

Firebug would show a 200 OK on the request for the admin_menu html - http://test.wc.sparta/js/admin_menu/cache/2dbddf951b37bf61fee7a93b0eddf5a5 but the response is empty - Drupal was not sending any html back when views_filters_selective was enabled.

Following the php tag and encoding hints by some legendary peoples in this thread, I checked each file for encoding by running:

file -I views_hacks/views_filters_selective/*

This showed that: views_filters_selective.info, views_filters_selective.views.inc and views_filters_selective_exposed_form_plugin.inc were all us-ascii encoding.

BUT, views_filters_selective.module was UTF encoding. So in my code editor, I used the save as encoding feature to save as us-ascii encoding.

After saving the file as us-ascii, the editor showed 3 crazy characters before the <?php open tag.

I deleted these 3 characters, saved the file, and admin_menu started working again.

With the editor and encoding issues, the 3 insidious characters causing the problem were invisible to me.

Without the encoding and character spaces hint in this thread, I would have had no chance of solving the problem as I couldn't see it. Invisible characters are one of those problems where you end up stabbing your eyes with forks.

But because of the good hints in this thread, I didn't have to. Thanks!

where is this at? was at 1.8 which seemed pretty stable except for issue with hiding menu items that should have been there. upgraded to latest 3.x-dev and seems to be quite a mess at the moment.

- menu is only randomly visible or takes a very long time to display after page has loaded (weird)
- in Chrome it is never visible
- Create Content is missing
- still unclear how to get new menu items to display
- clearing admin menu cache wiped out Content Management menu and flatted all the items to the top level (http://screencast.com/t/uJp6eIPm)

i'll go back and try 3.x-alpha but sounds as though it doesn't work either - perhaps better to go back to 1.8 and try to debug why items only show if other items are enabled.

@willieseabrook

Those "3 crazy characters before the <?php open tag" are the BOM (http://en.wikipedia.org/wiki/Byte_order_mark), something very annoying that generally appears when you're editing a file that has been edited previously under windows OS.

I guess some modules have been edited this way and saved with BOM... Hard to find bugs since you need an hexa editor to view the BOM.

Edit : maybe this is a way to solve this : http://thegreyblog.blogspot.com/2010/09/shell-script-to-find-and-remove-...

For D7, I experience this and I updated my views to views-7.x-3.x-dev and it worked well for me.

I have a website running on Drupal 6 with a theme created with the dreadful Artisteer 2 theme creator software. This theme looks good but if you want to make any change to the theme, prepare yourself for an awful war. I made a little change at the bottom of the page and the Admin Menu stopped working.

The whole theme is heavily based on JavaScript that will break as soon as you delete an obscure <div> that doesn't seem to be doing anything. I got stuck with this theme and whenever I make a change on the theme page I feel like I am walking on a minefield.

So, if you have a theme that has a lot of JavaScript, changes on the theme might be the reason why your Admin Menu stopped working.

If you are writing a module that uses JavaScript, check your JavaScript code to make sure that you are not starting the problem yourself.

Subscribe.

Subscribe. Applied fix #61; working for now.

Subscribe. Happened only upon enabling JavaScript aggregation. Not using SecurePages.

Subscribe. Fix #61 didn't change anything for me.

Changing the PHP memory limit to 96M (it was 32) worked for me on both a Drupal 6.22 and a Drupal 7.7 install.

Best regards,

Julius

Subscribing. The patch in #74 didn't fix this, and my memory limit is already 128M.

My PHP max_execution_time and max_input_time are both 200. How much are yours?

In my case I had a custom module enabled which contained some cyrillic characters. File encoding is UTF-8. Changing the enconding to ANSI made the admin_menu appear again.

In my custom module I removed the space before beginning of the PHP tag

   <?php
// code ...
?>

And Hop ! the admin menu was back

The cause and solution mentioned in #101 and earlier seems to be the case for almost everyone...

Wondering whether admin_menu could do something about it. Although that mistake/error could probably be hidden away by starting an output buffer before attempting to render the menu, but I think that would be wrong. So I wonder whether we could determine whether some unintentional output has been produced during rendering, and throw an error message in that case. That said, this check should ideally happen on the Status report / requirements check page, and not during regular runtime.

Lastly, not sure whether this can still be classified as a stable release blocker.

I had the same problem as #101 except I had a few hard returns after the closing php tags ?>

Removing those fixed the problem.

I just had this problem on D7.7 site with custom theme and only 1 contrib module installed (google fonts).

Fixed by removing blank line before <?php in template.php file of my custom theme.

Lovely. Fixed this by adding php opening tags to the empty .module files of some of my custom modules. Didn't realize it was necessary to have <?php in empty .module files.

I was having the same problem in admin menu, when i enabled my custom drupal module.
Remove extra space above <?php and the problem will resolve. (As mentioned in #101). But still its really problematic to understand this issue.
Because it seems that issue is related to java script.

I have this problem if I enable the "Aggregate JavaScript files" option.

after much frustration I think I found the cause of my problem, the Ligjhtbox2 module. I uninstalled it and replaced with "colorbox" and now I can aggregate js & css with no affect on the admin menu.

In my case, my template.php (from Zen) was missing the closing for the php container. I added ?> to the end of the file and the admin menu now seems to appear consistently without cache clearing or anything.
I'm a bonehead. See #112

#66 thanks! Turns out that was exactly the problem. I had enabled "Aggregate JavaScript files" to increase site speed and shortly thereafter I noticed the Admin bar had disappeared. As soon as I turned this off again, everything was fine. What a pain!

You should always avoid using the php closing tag at the end of your file. The php engine will close your file automatically. I found out about this little trick with the good fellows at lullabot.com. Their tutorial videos are awesome...

@drupalfever, OK, I see at http://drupal.org/coding-standards#phptags that removing the closing delimiter is optional and in some people's opinion a best practice.

I removed the closing delimiter from my template.php and cleared my cache. The unwanted behavior did not return. I have to assume that the change I made was coincidental and that thinking that it fixed the problem was just boneheaded. Will strikeout my above recommendation.

I have a similar problem, but I do not really know if I should open another issue, or is related to this one.

I have recently migrate some sites from GoDaddy to HostGator hosting, and now, when I log out from any of the sites, the admin menu is still there. However, I am not logged because when trying to access to an admin page, it says "pemission denied" or something like that. If I clear the cache from the browser, the menu disappear.

This is happening when the caching mode in Drupal is normal, but not when it is disabled. I have tried several of the solutions presented here without luck. The only workaround for now seems to be disabling the caching.

Committed #74 also to 6.x-3.x.

sorry. why is this fixed?

guessing must be similar issue. as posted months back on this thread i had issue with admin menu not showing up at all or taking a very long time to show when i went to 6.x-3.x rev. Never found a solution so went back to 6.x-1.8

now, have been working with D7 for a while and a site we have been developing for quite some time and all of a sudden (obviously not; we did something; but havent done much and have backrevved to a few days ago with no success) admin menu is showing same issue.

on all pages the admin menu takes 10-20s to load

also, if i clear caches, it looks as though the first new page load it loads instantly

i have latest devs of admin menu, views, core and any other module i suspected.. and no improvement

Not sure that this is really closed. I'm having the same symptoms on 7.x... admin menu disappears until I click something on the page. Flushing caches helps for a couple of pageloads, if it helps at all (seems intermittent).

The module works fine on my local environment, (MAMP) Apache with PHP 5.2. On my dev server, NGINX with PHP 5.3, it exhibits these symptoms. Maybe it's environmental?

just for the record; my very slow loading of admin menu seemed to happen all of a sudden on both my linux server and my win7 dev system. but shortly afterwards (like the next day) it seemed to be ok on the linux box and has remained that way. But has never recovered on the windows dev system.

i have done a clean checkout of the site and they have the same db.. but still no fix.. admin menu takes about 10-20 sec to load.

@liquidcms: Hey Peter, I haven't had this problem for some time now, but I reckon this could prove to be an issue with browser specific caching. Could you see if on your Win7 machine this happens with various browsers (if using firefox try a new profile too) or if the issue is browser-agnostic? Thanx in advance.

I created a patch with the solution in #61 for those of you using drush make.

@klonos, issue is not browser specific

Hi,

For me what fixed the issue is to change the PHP.ini file. I had:
zlib.output_compression = On
which I changed to
zlib.output_compression = Off

I hope this helps somebody :)

son of a bitch!! @dmartinc.. that seems to have fixed it.. not sure how that impacts all my other projects.. which btw, all have admin menu and all worked fine

and just checked my linux server and it is OFF there as well (it was working there).

At least two of my setups (one D6 and one D7) that I don't have the issue with also have zlib.output_compression set to off.

although.. have to reiterate... my local devel system which did have zlib.output_compression = on; was only busted with one of many sites running there. only one of my D7 projects had the admin_menu "busted" until i disabled zlib.output_compression

> now, have been working with D7 for a while and a site we have been developing for quite some time and all of a sudden admin menu is showing same issue.

Same story here.

Patch in #120 appears to fix the problem.

#120 Helped me :)

#61 worked for me

#61/#120 didn't work for me on a Drupal 7.10 :(

with my latest installation the problem is like that:

when i finnished creating the site i enabled file aggregation and file compression. everything worked fine for weeks. today the menu randomly disappeared until i cleaned the cache. but i had the same problem after every single following click. i figured out that it only happens when file compression is enabled.

Ack. This just started occurring here, seemingly at random. Admin menu disappears on each page load, only a cache flush will get it back.

No new modules were installed before this occurred. I disabled Apache mod_deflate, disabled all custom modules, set default theme and admin theme to Bartik, disabled all Drupal caching and compression. No errors in the Drupal log, no javascript errors in Safari console. Still occurring.

A full Safari reset restored normal behaviour. Not the first time I've had funky cache behaviour in Safari...

If anyone is having this trouble on Win.. I'm using Notepad++ as my editor, and what finally worked for me was to open admin_menu.module in Np++ and then go up to "Encoding" and click on Encode in UTF-8 without BOM.

Seems to be back now..

#66 worked for me! thanks.

So strange, I simply created an empty custom module, and the menu is disappearing on some pages (always the same pages, but I can't find the logic)...!

#61 worked for me, #66 did not, thanks!

Subscribing

My guess is that this is an issue related to Drupal's performance option to compress cached pages.

Taking a look at Admin Menu module code, there is a snippet that checks for 'page_compression' Drupal's variable (which defaults to TRUE) in order to compress the admin menu output as well. The problem is that this option is set to TRUE (by default) even if pages caching is not enabled, so admin menu generates compressed output, even when the page itself isn't being compressed, leading to the error.

I have disabled 'page_compression' (under http://chapstick-contest.localhost/admin/config/development/performance - option is only shown when "Cache pages for anonymous users" option is enabled) and Admin Menu is working properly now.

Hope that helps.

[]s
Ivam

this happens to me recently, i guess since a recent google chrome this weekend (using 16.0.912.75 now).
no problems in firefox so far
-- edit --
seems like restarting my mac just fixed the problem :)

Hi, not entirely sure what's causing this but setting the variable admin_menu_cache_client to FALSE worked for me. Can use drush vset admin_menu_cache_client 0 if you have Drush. Hope this helps.

Edit: Erm, didn't see this was mentioned above already. It's a long thread after all.. :P

Wow. This worked perfectly. Thank you so much!!!

#61 worked for me.

Drupal core 7.12
Administration menu 7.x-3.0-rc1+24-dev (2012-Feb-06)

I had two hard returns at the bottom of my template.php. Removing them resolved the issue with admin_menu not appearing.

This has been annoying me for a while now. #61 does work. But so does #133.
I assume that as #133 is not changing any of the code it would be the better path to try.

Hope that thought helps someone.

#21 works for me on a D6 site with secure pages + hijack sessions.

after trying most of these suggestions only #15 worked for me. thx

#122 seems to have done the job for me.

#15 solved the problem form me... Thank you, sun.

#137 helped me

I didn't have any issues with this until upgrading my server to php 5.3.10.

#15 "solved" the issue.

Thanks #142!!!!! That was my problem!!!!!

I've seen a lot of possible causes of admin menu disappearing, I think it would be a good idea to write some kind of troubleshooting guide to solve this and attach it in the module page. Much better than a forum topic with 150 replies.

#139 worked for me. Really don't need to cache Admin Menu since is used by site admin only.

I'm having this trouble again, but none of the solutions seem to apply (apart from hacking the module)

* works fine on my localhost (MAMP), but has this issue on my dev server (AWS with NGINX)
* Menu re-appears after a cache clear, but only on the first page load
* Happens independent of theme: in my admin theme (Seven), and in the front-end theme (Garland)
* Happens independent of browser.

But here's the observation I have that I haven't seen elsewhere: eventually, the menu will appear. If I wait about one minute, it will appear and work just fine. My JS error console says
"Uncaught Error: "create" can only be used in extension processes. See the content scripts documentation for more details.
148 event.layerX and event.layerY are broken and deprecated in WebKit. They will be removed from the engine in the near future."

This is from chrome-devtools://devtools/extensions/schema_generated_bindings.js:662 .

After I wait the minute, the menu seems to work fine. I can always make it bork out with a hard refresh, though.

Are we any closer to finding a solution here?

#78 did help me. Thanks a lot!

I fixed the disappearing admin_menu after cache clear on my site by adding $page_top and $page_bottom into html.tpl.php

The body section of my html.tpl.php now looks like this...

<body class="<?php print $classes; ?>" <?php print $attributes;?>>
  <?php print $page_top; ?>
  <?php print $page; ?>
  <?php print $page_bottom; ?>
</body>

Just in case that provides a hint on the root of the bug : the admin menu disappeared randomly when I turned on a module from Views Hacks : Views Selective Exposed Filters.
It worked back again when I turned it off. Easy to verify.

Hey all, I've just attempted to summarize the issue on top; hope it's helpful. I also notice that if you wait a while, the admin menu will appear, and in Firefox pressing the Esc key on page load will cause it to appear instantly. Unfortunately I didn't have time to do a lot of troubleshooting, so I just contented myself with turning off caching as mentioned in #15 and that worked fine. I'm not entirely sure why caching the admin_menu is important, or if this will have other repercussions, but it doesn't seem to slow down the site at all.

Seems odd to me that file encoding differences can cause / fix this problem, or that extraneous characters around <?php?> tags could cause the javascript not to work while normal pages still do work. But that appears to be the problem much of the time.

@FranckV

Look this issue you are talking about is due to something called BOM. Just remove it from the Views Selective Exposed Filters module's file. I did that using the Linux text editor. Now both modules work together nicely.

Hey Sun,

Thanks so much for this, I've been wondering why all of a sudden a few months ago all of my D7 sites admin menu stopped working properly and very inconsistent behaviour. We use BOA hosting system by @omega8cc and I can confirm on D7 this fix works a treat. D6 doesn't seem to be affected at all for us.

For BOA users:
touch the local.settings.php file into your platform dir and link the file into your site dir.

My local.settings.php file looks like this:

<?php
$conf['admin_menu_cache_client'] = FALSE;

Not the trailing ?> is not included by design.
Many thanks again! Great module and some people ought to be grateful it exists at all and that you continue to support it! :)
I'd love to see this module in core someday, I always remove the toolbar + overlay for this on every build!

I finally found the issue for my install after a lot of time debugging.

The issue was coming from the context module, specifically: context/plugins/context_reaction_block.js line 3

See http://drupal.org/node/1514036 for a more thorough explanation

Also, of note there is potentially a core issue, but I haven't yet decided if it's a bug, I need to research further, but if you are using Seven as your theme, it also produces errors of this nature in D7. I'll update later with if that is really a core bug or not.

...I haven't replied in this issue for so long and I am aware that what I am to say if off-topic, but:

... I'd love to see this module in core someday, I always remove the toolbar + overlay for this on every build!

That's why we should "push" to implement #1036780: Drupal.org should collect stats on enabled sub-modules and core modules and try to collect some stats in order to convince people that the out-of-the-box experience of Drupal needs to have some sensible defaults. For me too, this means to have the overlay.module disabled by default (if not out of core and into contrib) and try to get admin_menu in core instead of reinventing the wheel and implementing a new admin "toolbar" from scratch.

I noticed today that enabling any of the message altering modules, ie. drupal.org/project/better_messages or any of the others, that the Admin menu looses almost all its links, all that remains is Home, Content & Structure drop-downs, all icons & links are gone on the right side of the menu bar too. Clearing the caches brings them back but only for one page load, then back to disappeared on any consecutive page loads.

It took me a bit to figure it was the message altering modules & it doesn't matter which one, though I cant figure why yet. I have no other message altering stuff in my theme or custom modules.

Im using jquery 1.7 that comes with the jquery update module, and the latest dev of admin_menu set on the toolbar option.

hmmm seems turning off the (admin_menu_toolbar) sub module the problem goes away, well thats where at least my issue is.

Ooops... make that turning off client side menu cache fixed it for me.... toolbar style wasn't it.
"Cache menu in client-side browser" in /admin/config/administration/admin_menu
For some reason the cached bit is missing most of the menu tree when it renders.
Firefox 11

Confirm #158 worked for us on BOA!
Thanks @snlnz

We also are using the dev version now. Install of dev alone did not fix our issue. :-(

I think I have tried every suggestion offered on this page. I still can't get the admin_menu to show up consistently on all my pages. It shows immediately after clearing cache and soon as I start browsing my site, it's gone and stays gone until the next time i clear cache. This is my favorite module. What gives?

Just want to add my 2 cents worth. This is what i did and it fixed it. I went to the performance page and unchecked all caching saved and then rechecked all but the compress cached pages and saved and now it seams to be working fine. May be a temp fix if you don't care about compressing cached pages. Hope this helps someone else.

#158 worked, even though it's not an ideal solution...

Thank you for the succinct summary at the top! Because of that summary, I found the solution to just disable menu caching entirely, per comment 158. I like it especially because the change can be in settings.php, which is site-specific anyway. Somehow this is an issue on my dev server, but not locally or on my production server. :| Anyway, happy to report a fix!

Let's try something completely new. :)

To clarify:

1. This patch replaces admin_menu's custom caching for the JavaScript callback that leverages client-side HTTP caching.
2. Instead of the custom code, the page callback enforces Drupal's regular page caching to be enabled, and then goes ahead and re-uses all of Drupal core's regular page caching functions to build and deliver the cached content.
3. Since Drupal core does not allow page caching for authenticated users, a few lines of Drupal's early bootstrap code that's responsible for delivering a cached page need to be duplicated into the page callback, so the response is actually delivered from cache.
4. The client-side HTTP caching is actually triggered through the Expires HTTP header only. The additional server-side cache only takes effect when a client requests the callback URL again (e.g., after clearing the browser cache or when force-reloading a Drupal page).

Added more docs and cleaned up surrounding code. Tempted to commit this patch to enforce crowd testing.

#170: admin_menu.cache_.170.patch queued for re-testing.

Thanks for reporting, reviewing, and testing! Committed to 7.x-3.x.

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

only 3 years in the making. ++

I try with the 7.x-3.0-rc2+3-dev and it works! Big thanks :)

This was my problem too!! Thanks macrocosm! I was using Chrome.

#163 worked for me. I had been using toolbar style for some time with no trouble. After updating drupal core from 7.10 to 7.12, the toolbar was almost never appearing at all. I disabled menu caching as described and it fixed the problem; works great now. Thanks.

#139 worked perfectly, thanks!
drush vset admin_menu_cache_client 0 then hit 1 and enter!

Upgraded to rc2 and got both incomplete menu rendering and 404 access errors as primary user 1.

Applying #170 (or latest dev release) results in an entire rendered HTML page being AJAXed into the page footer. I reverted to rc1 without errors.

This site has at least 100 contrib modules and 20 custom ones. Memcache integration, Entity API & sub-modules and Domain Access are the main heavy weight modules off the top of my head. It would take days to disable each one by one, hit cache flush twice ...

Loading the ajax cache callback directly renders a fully themed page with menu listing.

http://www.example.com/js/admin_menu/cache/36c06844e1e957cc2eebd309afd53ff8

On a simple site with maybe only 40 contrib modules, I did not get any issues. This has the same core / contrib menu related modules as per the bigger site; superfish, menu position, etc.

While not helpful, reopening based on the side comment in #170 "Tempted to commit this patch to enforce crowd testing.". Sadly an non-descriptive crowd response.

Good news, the menu renders fully on both sites :)

This fix is only contained in the 7.x-3.x-dev snapshot right now.

When testing that, do not forget to run update.php, because the menu has to be rebuilt.

Update, rebuild admin menu, rebuild menu, clear all caches, disabled 5 or 6 "possible" issue modules with cache clears after each disable...

Note when upgrading or reverting, and with no caching clearing, I had the menu completely disappeared on both sites, so that should stand out fairly clearly in the issue queue.

I think that I will let the dust settle before trying again, but happy to following any debugging advice that you may want to get more info on, using dprs or var_dumps in the code, etc. (other than disabling modules as this would take days to do one by one)

PS: I didn't report in the Devel queue, but the kumo class file has trailing whitespace, but this is only included when dpm is called, which wasn't the case during my testing.

I ruled out fairly much everything else in the issue summary, although the file scans were based on a couple of simple regex's. These may have missed things.

#163 worked for me.

BEFORE:
Report, many links under Configuration and the left side of the toolbar (welcome User) disappeared.
They render just in the page after flush cache. After one page browsing, the items disappeared again

#163 SOLUTION:
"Cache menu in client-side browser" = OFF

NOW:
everything works ok

MY CONFIGURATION:
drupal 7, hosting linux, firefox 9

Turning off "Cache menu in client-side browser" fixes the menu here, before it lost almost all parts of the menu tree on browsing.

Drupal 7, Opera 11.64.

Following #182 and deselecting "Cache menu in client-side browser" also resolved this for me.

#169: admin_menu.cache_.169.patch queued for re-testing.

@Damir:
A fix for this issue was already committed (#179.
Commit: http://drupalcode.org/project/admin_menu.git/commit/5a3895a

That fix was done on 2012-Apr-30.
The most recent release of this module was 2012-Apr-23.

So, until a new release is rolled, you will need to use the -dev version.

I was working with a custom theme and it turned out to be missing $page_top and $page_bottom in html.tpl.php.

Fix number 12 worked for me As in Comments #85 and #154 above.

Example of fixed body section from html.tpl.php:

<body class="<?php print $classes; ?>" <?php print $attributes;?>>
  <?php print $page_top; ?>
  <?php print $page; ?>
  <?php print $page_bottom; ?>
</body>

I'm just learning designing a web page using drupal - Blue Master theme, and when I login the next day, I can see my web page but there was no administration menu toolbar, nothing to clicked on, is it hiding from me? What have I done?

Good lord. Reverting issue properties. Will also close comments. This issue holds many answers. Furthermore, rc1 is 2 releases behind.

I'm going to attempt to summarize this issue.

Added command to automatically find occurences of space before <?php

In my case mod_rewrite was not allowed in Apache.
putting rewrite.load to the mods-enabled folder and restarting the webserver solved the issue

Adding the following fixed the issue for me.

$conf['admin_menu_cache_client'] = FALSE;

I am noticing an issue after installing and configuring Memcache. There appears to be a conflict with admin_menu module.

The issue is that when CSS/JS Compression/Aggregation is turned on, the admin menu (black bar at the top) does not show. Intead of the black bar, it basically just shows a white bar, like it knows it should be showing there, but isn't.

When I turn those settings off, it shows fine. But, it would be great to have this work when the compression setting is turned on. Any ideas?

After some more review, I noticed the issue ONLY happens when "Compress cached pages" is turned on.
CSS/JS Compression/Aggregation setting has no effect.

When I turn off that setting, all works fine. Is there a patch available to address this issue? Does patch #170 fix it?
Memcache 7.x-1.1
Admin_menu 7.x-3.0-rc4

@joshua.boltz
Maybe create a new issue for this?

You probably figured out why I was having issues in #170. That site had every module in the book thrown at it including memcache, but I did not try disabling memcache at the time.