jacmkno’s picture

I made this change in the module code. This kills the menu cache but at least the menu shows up and works properly.

Line 335: $cache = NULL; //drupal_page_get_cache(); // This cache causes the menu to disappear sometimes

sun’s picture

@jacmkno: The line right after that checks whether there is any $cache.

So what you're saying is that the $cache record created by Drupal core, if returned, does not contain the menu.

In turn, I'd like to know what a var_dump($cache) shows in that case.

deggertsen’s picture

Same issue using the same version (7.x-3.0-rc3). I had to kill the menu cache as well by using the method mentioned in #1.

@sun if you can briefly explain to me where to put the function var_dump($cache) so I can get you that output I would be happy to do that.


sun’s picture

When the menu disappears again, execute these steps in the exact order:

  1. Enable Firebug or whichever browser console, so you see Ajax requests being performed.
  2. Reload/re-access the page.
  3. Copy the Ajax request's URL, which should look along the lines of:


  4. Access that URL directly. (It will probably show an empty page.)
  5. Inject a var_dump() into admin_menu.module, line 335:
      $cache = drupal_page_get_cache();
  6. Reload that URL. Save the page into a .txt file, and attach it here.
sun’s picture

Title: admiin menu disappears randomly (again) » Admin menu disappears randomly (again)
joachim’s picture

Interestingly, I set up a new site today with the latest admin_menu downloaded by drush, and didn't see any problems with it.

Perhaps the problem is with upgrading from an earlier version?

(Not at my main machine, so can't do the ajax debug right now, sorry!)

WVxNitemare’s picture

Subscribed. We are having this same issue here on random machines. Have applied the work around in #1 for now, however the load time for the menu is now brutally slow.

sun’s picture

@joachim: That's interesting, but I rather suspect a platform/environment difference. That is, because earlier versions also used a cache, and all caches are entirely flushed when running update.php, so there's really no chance of stale data leaking into the current version.

deggertsen’s picture

@sun, I've tried to follow the steps you gave me and got to step 4. Instead of showing me a blank page it gave me this:

Content Encoding Error
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
Please contact the website owners to inform them of this problem.

I tried to continue on with the steps, but it continued to give me this error. Any ideas on what this means?

One thing to note. That URL in the console shows an error normally, but when I comment out line 335 the error goes away.

sun’s picture

Err, ok. The entire intention of replacing admin_menu's custom caching with Drupal core's regular page cache was to finally get rid of and resolve that content-encoding error. ;)

Since we're using straight core functionality now, my suspicion is that this must actually be a bug or weirdness in Drupal core's page caching. Searching for the error you mentioned yields:

It's noteworthy that most of those issues are reporting differences in reproducing the respective issue

1) in different browsers
2) with varying aggregation + compression options in the system performance settings
3) with different web servers
4) depending on the existence of a reverse-proxy (e.g., Varnish, Akamai, etc)

In any case, can you still complete steps 5+6, please? The dumped $cache should show HTTP response headers and the actual content being sent.

deggertsen’s picture

There must be something I'm not understanding here. I've attached a .txt file of the saved page with the dumped $cache, but as you can see it's not giving any useful information other than the error I already gave you. Is there a certain way I am supposed to save the page?

deggertsen’s picture

Here are some response and request headers from the firebug console:

Response Headers

Cache-Control     private, max-age=31536000
Connection        Keep-Alive
Content-Encoding  gzip
Content-Language  en
Content-Type      text/html; charset=utf-8
Date              Thu, 05 Jul 2012 17:47:51 GMT
Etag              "1341509869-1"
Expires           Fri, 05 Jul 2013 17:37:49 +0000
Keep-Alive        timeout=5, max=89
Last-Modified     Thu, 05 Jul 2012 17:37:49 GMT
Server            Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/1.0.0g DAV/2 mod_bwlimited/1.4
Transfer-Encoding chunked
Vary              Cookie,Accept-Encoding
X-Drupal-Cache    HIT

Request Headers

Accept            text/plain, */*; q=0.01
Accept-Encoding   gzip, deflate
Accept-Language   en-us,en;q=0.5
Connection        keep-alive
Cookie            Drupal.tableDrag.showWeight=0; Drupal.visitor.admin_compact_mode=1; __utma=13249770.602854895.1330422802.1341502229.1341508646.135; __utmz=13249770.1330422802.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SESSda042bd25c19aae0262aebd419c2da4c=H1-SIuqx0g7rpq0w7uwGsiTCdT8Iqm7SYBtnLDPx8kk; ctools-collapsible-state=views-ui-advanced-column-resource_center_search%3A1%2Cviews-ui-advanced-column-resource_center_browse%3A1%2Cviews-ui-advanced-column-weight%3A1%2Cviews-ui-advanced-column-control_content%3A1%2Cviews-ui-advanced-column-speakers%3A1%2Cviews-ui-advanced-column-wishlist%3A1%2Cviews-ui-advanced-column-reviews%3A1; has_js=1; __utmc=13249770; __utmb=13249770.7.10.1341508646
User-Agent        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
X-Requested-With  XMLHttpRequest
joachim’s picture

Huh. I've reverted my revert of the update to rc-3 and now I can't reproduce the problem! Just spent 5 minutes walking round my localhost and admin menu shows up everywhere!

joachim’s picture

Ok I've now got this going wrong on another local site I've just updated:

Enable Firebug or whichever browser console, so you see Ajax requests being performed.
Reload/re-access the page.
Copy the Ajax request's URL, which should look along the lines of:

Maybe I'm doing this wrong, but I don't actually *see* the ajax request there at all.

I'm in Firebug's 'Net' tab, with 'All' selected. All I get after the initial URL request is JS, CSS, and image files.

EDIT: Never mind, a cache clear in the right drush alias (doh!) fixed it.

sun’s picture

Version: 7.x-3.0-rc3 » 7.x-3.x-dev
Status: Active » Needs review
544 bytes
PASSED: [[SimpleTest]]: [MySQL] 228 pass(es). View

@deggertsen: Did you check any of the core issues I linked to in #10?

@all: Is it possible that you only get this error with Firefox?

Also, I somewhat doubt that attached patch changes anything, but can you try it? You need to clear your browser cache + flush Drupal caches after applying it.

deggertsen’s picture

The patch doesn't seem to help.

There are a lot of core issues in #10. I have not reviewed them all, though it seems likely that it's a core issue rather than an issue with admin menu.

I've confirmed that at least for me the problem is only when I'm using firefox.

I just tried something that does seem to have fixed it for now though. I had tried clearing my browser cache before, but not cookies. So I went in and removed all cookies for the site and now it appears to be working just fine. This is with the patch still applied. I am now wishing I would have paid closer attention to the cookies I removed to see if I could see which one was causing the problem, but for now at least that fixed it.

I tried this because of the link ( you referred me to.

If the issue comes back up again I will pay closer attention to the cookies.

deggertsen’s picture

Priority: Critical » Normal
Status: Needs review » Active

I've found that I can fix it by removing a cookie for the site in firefox with the following info:
name: SESSda042bd25c19aae0262aebd419c2da4c
content: 86I0oG9N4Ux9sBmyDDs4cYRxpE8V21gHbvg_vjwgD4w

It seems to be a firefox session cookie. When I remove the cookie I have to log back in, but the menu will work for awhile until it stops working again. Don't know if this information helps anyone, but for now I'm just gonna have to go with the workaround from #1 or use chrome instead of firefox.

kip stanning’s picture

same issue (admin menu randomly disappearing and reappearing after clearing cache) appearing in chrome as well. i would like to apply hints in #1 but can't find the place to put that line. as far as i understand the line
$cache = NULL
should be inserted. it would be nice to include the line before and after the line to be inserted so i can find the proper place in admin_menu.module.
btw: my version is 7.x-3.0-rc2


gagarine’s picture

Same problem.

What is funny is than I have the admin menu in seven but on my front-end theme it disappear and only appear one after a cache clear.

My theme is subtheme of the html5 version of

EDIT: #1 doesn't help so I think is another problem.

cmccluskey’s picture

Priority: Normal » Major

Same problem here too... Just started today though???? And, it's not just a Firefox issue. Does the same thing in IE 9.

lord_of_freaks’s picture

Status: Active » Needs review

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

sk33lz’s picture

Tested this on FF, Chrome, and IE9, and it is not working. Tried the patch in #15 to no avail.

Also tested this on WIndows running Apache, and Ubuntu running Nginx with the same result.

I am running 7.x-3.0-rc3 (patched from #15 above) and Drupal 7.15. Neither of the sites I am troubleshooting this issue on have page/block caching or CSS/JS compression turned on.

Something is seriously wrong with the core page caching integration, or the core page caching itself it seems.

In the end I have applied the hack in #1, as I use Admin Menu on every site I run/build and it's being downloaded by Drush as the recommended release.

sk33lz’s picture

For good measure, I have tried the steps in #5, and get no response after injecting the var_dump($cache);.

In fact, I get an error:

Firefox Error
Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error.

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

I have absolutely no clue what those mean, but perhaps you can gain some insight form them to fix this issue.

Good luck and thanks for your hard work and dedication to the Drupal project.

patbranch’s picture

I've been dealing with this for a few hours... Unchecking 'Cache menu in client-side browser' seemed to fix it.

Stuart’s picture

I have been using Administration menu and its toolbar (7.x-3.0-rc3) for some weeks on a site I am developing, so far on localhost, with the development machine running Windows 7 SP1 and Firefox. I only started suffering from the toolbar disappearing (and very occasionally reappearing) apparently at random in the last few days and it seemed to start after Firefox updated itself to version 15.0 - although I cannot be sure that this is what set it off.

I have tried unchecking 'Cache menu in client-side browser' as suggested in #24 and, so far (fingers crossed), it has not happened again.

gambry’s picture

Just to give my 2cents.
The Admin menu was and is perfectly working on my localhost test (apache 2.2.16 web server on ubuntu).
Just uploading the website to the stage server (apache 1.3.42 on CentOS) and it stopped working.
Could it be server-side related?

Anyway unchecking 'Cache menu in client-side browser' as suggested in #24 works.

laura s’s picture

Title: Admin menu disappears randomly (again) » Admin menu disappears randomly (again) if client-side cache option enabled

I can confirm #24 as well. Disabling "Cache menu in client-side browser" has resolved the issue for our team. (OSX Chrome.)

This seems to be browser-release-specific. Unlike as reported above, from what I can recall, I have not had this problem with the most recent Firefox releases. Was this affecting earlier releases? Or FF on certain OSs? I've noticed the disappearance issues in OSX Chrome, which is my primary browser. I'll watch for it now while working in FF.

ownage’s picture

Sad to say that unchecking "Cache menu in client-side browser" does not fix it for me in Firefox v16; in fact, doing so makes the admin menu ALWAYS invisible. Wish I could get this situation fixed as refreshing just to get the admin menu on every other page load is quite annoying.

The 20px top margin is always working, but the menu is invisible. Refreshing usually fixes the issue-- sometimes it takes multiple refreshes.

marblegravy’s picture

Just noting another success for disabling Cache menu in client-side browser in /admin/config/administration/admin_menu

I was experiencing the issue in IE8.

Stefan Vaduva’s picture

#24 works for me as well on Chrome (OSX and Win).

For #29: I also have the patch from #15. Do you have it applied?

lmeurs’s picture

#24 disabling "Cache menu in client-side browser" at admin/config/administration/admin_menu works for me too!

pagaille’s picture

Same thing here. In my case, I had the Agreement module enabled and, when logged in as anything but the admin user (admins bypass the agreement page), if I tried to navigate to another page or bypass the agreement in some way, the admin menu would disappear and the agreement form was duplicated at the bottom of the page. Disabling "Cache menu in client-side browser" resolved both of these issues.

To reproduce, just enable admin_menu, admin_toolbar and agreement modules. Go to agreement settings (admin/config/people/agreement) and select "On every login" under Frequency. Enter some test text in the Agreement Text field. Log out and log back in as a "regular" (non admin) user who has the "Access administration menu" permission. You should see the admin menu and the agreement page. Try navigating to another page: admin menu disappears and agreement form is duplicated at bottom of page. Try submitting agreement without checking "I agree" and same thing happens. If you disable "Cache menu in client-side browser" admin_menu and agreement both work as they should. Tested in FF 18.0.1 and Chrome 24.0.1312.56.

See also #1900442: Agreement form appears twice if user tries to navigate to another page without accepting it first.

RobW’s picture

#24 works for me as well, Chrome, Mothership child theme. It would be great if one of the module maintainers could add a comment at the end of the closed issue for others looking for fixes to this problem.

rankinstudio’s picture

#1 and #24 work. Are they doing the same thing?

muranod’s picture

None of these solutions work for me. Every time I change and then save a view, I have to flush the admin menu cache to see any links.

Is there a simple way to just have the flush happen automatically?

ownage’s picture

I agree with muranod, something needs to be evaluated because it is very frustrating to have to reload the page to see or use the admin menu. (My comment was #29).

mpastas’s picture

I think that the problem here unfortunately is the "Content-Encoding : gzip" enabled on the server. Please check if you have the content encoding enabled when the issue occurs.

DamienMcKenna’s picture

Am seeing this with v7.x-3.0-rc4 (using an AdaptiveTheme subtheme) even after disabling the "cache" option, have not dug into the problem yet.

gambry’s picture

mpastas should we check on HTTP headers?
If it's so... I don't have it.

Should we check on specific pages / gets or any?
Additionally... with the "cache" option enabled or disabled?

mpastas’s picture

Sorry, Gzip discarded. Gzip is not the problem here. But it only happens on the staging server, never on a localhost.

DamienMcKenna’s picture

@mpastas: I've had the problem arise on a local dev install (using MAMP).

rvdtuin’s picture

On my localhost no problems with admin_menu but
on the server the admin_menu doesn't work when selecting subs of content and some of the structure subs.
Instead I get a very large treemenu at the bottom of the page....
(Cache menu in client-side browser is not selected)

rvdtuin’s picture

Locahost was on DAMP(windows) and the Server is Unix.
I also got a messages that some temp. files couldn't be copied
the local file system path where temporary files will be stored wasn't configured properly.
Don't know what the path should be?

I disabled "aggregate and compress CSS files" and "aggregate JavaScript files"
Now behaviour as expected.

rvdtuin’s picture

DamienMcKenna’s picture

@rvdtuin: I've had the problem happen on local sites when JS aggregation is disabled.

muranod’s picture

I've tried enabling / disabling js & css aggregation & menu caching, but it still happens whenever I install a new module and every time I edit and then save a view. That's always two steps: Save the view / clear admin cache. (both on my DEV and LIVE sites.)

isholgueras’s picture

Same problem here.

I have five roles and two of them with permissions to see admin menu and access drupal links (admin/people/permissions and the checkboxes for that are checked for these two roles). The administrator role can see everytime the admin menu black bar but another roles (Editor, Moderator) can't. When I check the permissions page, the checkboxes for admin menu turn onto disabled state.

I think it's a cache problem, but I don't know yet why this checkboxes turned onto a disabled state...

I hope I can find a solution soon.

isholgueras’s picture

In our case, It was a problem of cookie session

In our "settings.php" we hadn't set the "$cookie_domain" and with the load balancer, it seems that was not saved correctly.

Now works correctly.

Andre-B’s picture

disabling client side caching fixed the disappearing admin module on my server too.

local with MAMP no problems. server specs for the testsystem on which this bug occurs:

  • Apache/2.2.16 (Debian)
  • PHP Version 5.3.3-7+squeeze15

additional info:

  • using adaptive theme with a subtheme (does not seem to be related)
  • using

addition debug info:
I dived into the output of the cached admin menu url. on the local server it outputs clean html, on the server it outputs html entities instead.

muranod’s picture

Looks like this is working for me. I just edited a view and the admin menu came back. Then I enabled and disabled a module and the admin menu came back for just half a second in the shortened version (basic functions only), then flashed back to the full admin menu. I had been my domain set without the www in, so I edited settings.php as Ignacio suggested and that seemed to keep the admin menu from disappearing/shortening after these operations.

UPDATE: NOPE -- just updated some modules and had to "Flush admin menu cache" again.

navoff’s picture

Same thing is happening to me as muranod. The update manager listed several modules that needed to be updated. So I selected and installed them. After that, the admin toolbar started only showing the Home icon and the Add Content link. I cleared the Administration Menu cache and the other links returned. However, they seems to randomly disappear as I'm working. I don't recall which modules were updated (since it's likely that installing one of those is what triggered the problem) and I can't seem to find a way to display when modules were last updated (if there is a way, I'd be grateful for instructions on how to do that). All I can mange to find at this point is the version number of each module and whether or not there are new versions available, not the date the current version was installed.

klonos’s picture

Ok, it's been really long since I saw this last time but I had this happen again after messing around with the site logo/favicon settings. After that, admin_menu wouldn't come up only on the site's home page - on all other pages it showed up just fine. Tried all sorts of things to no avail. Here's what finally worked:

- Disabled the client-side caching option.
- Cleared caches.
(at this point the menu returned on the home page)
- Enabled client-side caching again.
- Cleared caches once more.

So far the menu shows up on all pages. Hope this helps.

Ndesign’s picture


a fresh install of the current drupal 7.22 with admin_menu 7.x-3.0-rc4 does not have this issue for me...only updating older versions of my websites creates this issue

klonos steps only worked with the current login..after logout and login again still poses same issue.

cimo75’s picture

Same problem here, after upgrading a few modules and core to 7.23

kevinsiji’s picture

Status: Needs review » Active

Patch in #15 is not fixing the problem. No changes observed.

Below is the request and response headers of a successful admin_menu and disappearing admin_menu.

Differences we can found is:
Cache-Control: max-age=0
X-Drupal-Cache: MISS v/s X-Drupal-Cache: HIT

Successful admin_menu

Request Headers
GET /js/admin_menu/cache/b1afca03a6ca587e324c2fcc9b9900b8 HTTP/1.1
Connection: keep-alive
Accept: text/html, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ml;q=0.6
Cookie: SESS4eb11dbb91804a7c1c45f84fd6dba623=SGmGYxTxdR71hWiNIycKGiIQsRmHqUck2arDnJbK34g; openid_provider=drupal; SESS2914f803a81c2602ecf41147a4c86483=PuTHZP6SmpcNVFtApZEvMNtpWUS95ORoQmlOURBrN2M; has_js=1; __utma=70211347.58608502.1380434455.1380434455.1380434455.1; __utmb=70211347.11.10.1380434455; __utmc=70211347; __utmz=70211347.1380434455.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)

Response Headers
HTTP/1.1 200 OK
Date: Sun, 29 Sep 2013 06:24:43 GMT
Server: Apache/2.2.22 (@RELEASE@)
X-Powered-By: PHP/5.4.17
Expires: Mon, 29 Sep 2014 06:24:43 +0000
Last-Modified: Sun, 29 Sep 2013 06:24:43 +0000
Cache-Control: private, max-age=31536000
ETag: "1380435883-1"
X-Drupal-Cache: MISS
Content-Language: en
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Disappearing admin_menu

Request Headers
GET /js/admin_menu/cache/b1afca03a6ca587e324c2fcc9b9900b8 HTTP/1.1
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ml;q=0.6
Cookie: SESS4eb11dbb91804a7c1c45f84fd6dba623=SGmGYxTxdR71hWiNIycKGiIQsRmHqUck2arDnJbK34g; openid_provider=drupal; SESS2914f803a81c2602ecf41147a4c86483=PuTHZP6SmpcNVFtApZEvMNtpWUS95ORoQmlOURBrN2M; __utma=70211347.58608502.1380434455.1380434455.1380434455.1; __utmb=70211347.11.10.1380434455; __utmc=70211347; __utmz=70211347.1380434455.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); has_js=1

Response Headers
HTTP/1.1 200 OK
Date: Sun, 29 Sep 2013 06:28:10 GMT
Server: Apache/2.2.22 (@RELEASE@)
X-Powered-By: PHP/5.4.17
Expires: Mon, 29 Sep 2014 06:24:43 +0000
Last-Modified: Sun, 29 Sep 2013 06:24:43 +0000
Cache-Control: private, max-age=31536000
ETag: "1380435883-1"
X-Drupal-Cache: HIT
Content-Language: en
Vary: Cookie,Accept-Encoding
Content-Encoding: gzip
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
geerlingguy’s picture

Just adding a 'me too' here - don't have time to troubleshoot right now, but disabling the client-side caching seems to have fixed the issue on one of my sites.

muranod’s picture

I finally reached a point where I had to remove the admin menu module to keep from getting memory errors. I moved to a new host this past week and had my site migrated. The admin menu module worked again with no issues, AND the menu stopped disappearing after performing the same tasks that caused it to disappear on the old site. SO, could this issue simply be a matter of not having enough php memory for your site? I had 128M and now I'm at 256M.

klonos’s picture

...I always run on at least 256M though and had the issue happen to me.

jeff.esquivel’s picture


I was experimenting this same issue and fixed it by disabling Memcache UI.

It seems the problem was caused because Memcache UI appended some information about its use to every request made from an account that had the correct privileges (in this case, the admin account); the problem is that varnish interpreted that extra information as "garbage" (the exact error in varnishlog was "Junk after gzip data" when requesting some admin_menu related javascript file) and then proceeded to return 503 to the browser instead of the data that had been requested.

Aparato’s picture

Same problem, #57 (clear client-side cache) has cleared it for me AND I'd used jquery update to go to version 1.8 (needed elsewhere) and was getting the error "The dependency devel for the callback cache in admin_menu is not installed", the same action has cleared this as well! (I'll also raise that separately as it's a different problem).

codemode01’s picture

When running admin and admin_menu together, the admin toolbar randomly loses all menu links except for "Content". Client side cache does nothing for it. I've narrowed it down to saving views, which always causes the toolbar to lose it's links. The only fix I've found is to disable the admin module altogether.

smallcoder’s picture

Moved to new dedicated server recently and had this problem but following #53 solved it for the moment. Wish I could tell you why it worked but, as is often the case with Drupal, if it ain't broke... hope it stays that way !

cmonnow’s picture

Just so people who land on this page from Google are aware, some of the same suggested fixes in will work for you, which won't require any patches to the module.

If turning off client-side caching fixes your problem then I suggest you look for byte order marks (BOMs) ( in all non-binary files of your website (especially PHP files like .module). If minifying (aggregating and compressing) javascript causes problems you'd also want to look for BOMs in js files. Likewise I suppose for CSS.

In my case, the duplicate_role module's .module file happens to have a UTF-8 byte order mark (BOM) which is known to cause problems with Drupal (and PHP in general). Removing it fixed the problem (which was only happening in Chrome for me and not Firefox).

Step 1
Find your BOMs.
Instructions for Linux:
Open up a terminal and navigate to your website's directory (e.g. /var/www).
Enter grep -rlI $'\xEF\xBB\xBF' . to find all non-binary files that contain a byte-order mark. If you see any .module, .php, or .inc files you'll want to inspect them first in Step 2. Then javascript and CSS files.

In Windows you can use Total Commander (

Step 2
Backup your files to be changed. Then, open your file using your preferred text-editor.

Removing the BOM/signature is performed differently amongst the text-editors.
In Notepad++ on Windows or TextWrangler on the Mac you can remove the signature at Save As by selecting the encoding without a signature/BOM.

In Geany (Linux), go to Document in the menu and remove the tick next to "Write Unicode BOM" and save the file.

Step 3
Clear your admin_menu_cache (or all) and if you've fixed the problem file the fix should hopefully be permanent until your next dodgy file comes along :)

If the problem persists check the ideas in the link presented above. I've also had problems where text was inadvertently placed before <?php in my custom module and I have no idea how/when. If the problem recently started occurring and you haven't included any modules recently I would flick through your recently opened files for inadvertent text or spaces at the beginning of the file.

jazzitup’s picture

Issue summary: View changes

For all of you guys, this will probably fix your issue painlessly - just two lines of code:

grep -rl $'\xEF\xBB\xBF'  /var/www/your_drupal_project  > file_with_boms.txt
while read l; do sed -i '1 s/^\xef\xbb\xbf//'  $l; done < file_with_boms.txt

The BOM will be removed from all files in your Drupal folder recursively.

Guys from projects ckeditor and jquery_update have very serious issues with providing BOM files within their contributed code!

Note: Always backup your files first!

jazzitup’s picture

ttkaminski’s picture

Here's a command line to find all module or install files that have spaces before the open <?php tag:

find . -iregex ".*\.\(module\|install\)" -exec grep -e '^\s\+<[?]' -H {} \;

Run that in the directory where you have third party or custom modules. Edit any offending files to remove spaces before the open <?php tag.

kedramon’s picture

I found my problem in template, this can be easily checked after switching to default theme, if admin menu works in default theme (after cache clearing) be sure, the problem is there.
I also having problem with "typo" module, it opens with modal window without form.
So, in first site the problem was in html.tpl.php, there is a $page_top and $page_bottom variables that contain altered markup by other modules (contain admin menu markup), but in my file these two variable were deleted.
In second site there was no override html.tpl.php, but still have same issue, after few minute I found the bug, in page.tpl.php in the end of file i found unclosed comment tag <!-- Footer End stupid mistake.
Hope this helps.
Good luck!

srikanth.g’s picture

224.93 KB

My admin menu looks strange,all the duplicate menu items are displayed like: List List List...
I cleared/flsuh all the cache for menus/tables,then this problem came.How can i fix it?
Check the attached screenshot.

milos.kroulik’s picture

Regarding #65: Is the second step meant for all files? I thought, that it's a problem with text files.

firesidelibrarian’s picture

My admin menu disappears every time I scroll down. I have to run cron, then refresh the page to make it reappear. When I navigate to another admin page, it disappears again. Help!

upunkt’s picture

#64 and #65 fixed it for me. I had noticed the dis- and reappearing Admin Menu, but it started for me in a phase where I was mostly doing styling, so I did not care. I came here because finally Facebook Sharing did not work properly and the Facebook Debug Page showed errors, among them a notice about "malformed html", something I could not explain. Looking at the code the Facebook scraper was seeing I noticed all metatags being in BODY instead of HEAD and the document starting with

<!DOCTYPE html>

Searching the web I hit this thread. Using the script in #65 I found Byte Order Marks in several modules, some of them custom modules that got their BOMs due to wrong configuration in Dreamweaver, which I use for coding: Make sure to disable

Dreamweaver -> Preferences -> New Document -> Include BOM Signature

Hope this helps others.

jomarocas’s picture

i verified js and i have two ";" , verified the custom js for this, and i press "ctrl + scrolldown" and working, i dont know why but working, but works, if any try please comment

jazzitup’s picture


Using the script in #65 I found Byte Order Marks in several modules, some of them custom modules that got their BOMs due to wrong configuration in Dreamweaver

It would be great if you (or anybody else) could submit issues to the projects that contain BOMs, just like I did:

Thank you!

MatthijsG’s picture

Ran into this bug. #24 helped me .. but couldn't find the entry for the admin menu: it is admin/config/administration/admin_menu

harryqin’s picture

It seemed cache error. So I try to let it never create cache.


about line 315:

function admin_menu_cache_set($cid, $data) {

comments all inner codes, let this function do nothing.

It works for me now.

peterg.griffin’s picture

I agree, seems to be a cache issue as turning off the admin_menu cache via admin/config/administration/admin_menu worked for me. It's worth a try before stabbing any contrib module code..

johannez’s picture

Hello guys,

I actually had troubles with the admin menu showing up with the "Cache menu in client-side browser" option enabled. It usually happened after I flushed the cache and user login.
However, when I disabled that caching option, the admin menu completely disappeared. It was still there in the Seven admin theme, so it must have been something with my custom theme.
I forgot to put the page_bottom region into the .info file and html.tpl.php file. After I fixed that, the admin menu showed up stable on all my pages.

Hope this will help somebody in this thread. It's not the admin menu module, but your custom theme ;)


rcodina’s picture

Disabling cache for menu as it is said on #77 worked for me. Many thanks!

An smart solution to this problem would be to make the cache option for this module to be unchecked by default.

Richard15’s picture

Thanks! #77 works!

ragnarkurm’s picture

Admin Menu 7.x-3.0-rc5

Used tcpdump + wireshark to wiretap working and broken requests on URL such as

What I got confirms rotten server response case.

From successful http client-server conversation I was able to extract gzipped portion and successfully uncompress and obtain html.

From unsuccessful http client-server conversation I was unable to compress server response. Until I noticed that the response begins with space. After removing it I was able to uncompress it and the content seemed good html. Somewhere space leaks in, something like

return " $gzipped";

If this is general Drupal aggregation/compression problem then it must be much more palpable.
But it seems to show up only with Admin Menu.

ragnarkurm’s picture

After some more debugging, I nailed it!

Discovered that one of the custom modules began with ' <?php' (space in front of <).
It resulted space being outputted in front of compressed http response body
and therefore browser was not able to uncompress it. After removing the space
Admin Menu appeared.


It is not a bug of Drupal nor Admin Menu, but something else in-between. It could be virtually any module.

My suggestion would be to further develop drupal_load() function in core which would warn if a module outputs something during loading. It would probably save a lot of manhours hunting weird and very hard to find bugs (it is proved by number of posts in this thread (and probably in many others scattered around) over long period of time).

How to nail it?

Edit includes/ function drupal_load(). It is a short function. Find following line:

include_once DRUPAL_ROOT . '/' . $filename;

Temporarily replace it by

    include_once DRUPAL_ROOT . '/' . $filename;
    $value = ob_get_contents();
    if ($value !== '') {
      $filename = check_plain($filename);
      $value = check_plain($value);
      print "File '$filename' produced unforgivable content: '$value'.";

Reload any page and you will get faulty file. It could be in the beginning of the module/theme/etc, in the end (dont use ?>) or in any file which is included or required or by direct code execution (outside of function).

quantumized’s picture

THANK YOU @ragnarkurm (comment #82) - I would have never figured out the cause of my disappearing admin menu. After reading your post I was able to track down a leading space in the opening of a custom module. Removed it and the problem is fixed!

DamienMcKenna’s picture

@ragnarkurm: That's pretty great sleuthing. Maybe this should be turned into a documentation issue that notes this as a common problem that stems from errant spaces in custom code?

jmoruzi’s picture

@ragnarkurm thank you sir, the disappearing admin menu was driving me crazy. Your solution worked and showed me the error of my ways in my small custom module.

Homotechsual’s picture

Thanks @ragnarkurm - nailed it with the space preceeding an opening tag, going forward Drupal should probably catch these and deal with them appropriately.

Raher’s picture

Thanks #77
Disabling the cache menu in client-side browser worked me too!

gambry’s picture

Status: Active » Closed (works as designed)

So I'm assuming this issue can be closed as #82 clearly explains:
- issue is not related to admin_menu
- how to fix it

Eventually if you are not able to fix the issue you can always disable the client-side cache.

DamienMcKenna’s picture

Component: Code » Documentation
Status: Closed (works as designed) » Active

So lets make this a documentation issue.

upunkt’s picture

Thanks @ragnarkurm for #82.
With this method I found a custom module saved as utf-8 WITH BOM, a mistake thanks to Dreamweaver. So if you find these characters in the error message

it's a BOM-issue. Resave the file in question as utf-8 without BOM and it'll be alright.

yan’s picture

In my case #82 didn't give any hints, but #77 is doing it as a workaround.

zlatev’s picture


I have issues with disappearing admin menu only when memcache is turned on.
Memcache Version: 7.x-1.5
Admin menu Version: 7.x-3.0-rc5

Anyone with similar issues and ideas how to proceed without turning off any caching?

Homotechsual’s picture

Has anyone located a core issue for the fact that Drupal isn't catching the space before <?php and still attempts to cache instead of throwing an error with that module? If not this should probably be filed as a bug report against core.

Spurlos’s picture

I had the same issue with memcache and admin menu, and this comment helped me to solve it:

In short, check if apache has mod_rewrite enabled.

estoyausente’s picture

Confirmed that @ragnarkurm are right.

I had an space before <?php (I don't know why) and fixing it the problem is resolved. :)

jusfeel’s picture

This solution here to find the cause is breaking great news! Can't thank enough.

markcarver’s picture

See related issue for another possible fix.

derekrezek’s picture

I just truncated the menu_cache and flushed it. It is working now.

israel.tlachi’s picture

Thank you @ragnarkurm (comment #82) for the information from Mexico. It fixed my problem with my custom module.

dimon4ikzp’s picture

@ragnarkurm you are the best. #82 works for me as well

kriyar’s picture

Thank you @ragnarkurm (#82)
I spend almost a day to find out the error file, finally I found it with your code. :)

Really appreciate your great code!

Shashwat Purav’s picture

On "Administration menu" configuration page, under "Performance" tab, I just unchecked "Cache menu in client-side browser" option and it worked for me. :)