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

@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.

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:

   http://your.domain/js/admin_menu/cache/414f4468da483ed136463b262bdf6b88

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();
  var_dump($cache);
6. Reload that URL. Save the page into a .txt file, and attach it here.

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!)

@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.

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:

http://drupal.org/project/issues/drupal?text=content+encoding+error
http://drupal.org/project/issues/drupal?text=cache+content+encoding

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.

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

Response Headers

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.

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 (http://support.mozilla.org/en-US/questions/931166) you referred me to.

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

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

regards
karl

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

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.

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

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.

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.

#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?

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.

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

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).

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.

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

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)

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.)