Identical cache $cid incompatible with CacheRouter

I'm getting the same behavior on Drupal 6.10, RHE 5, PHP 5.1. Themes don't make a difference.

Clearing the cache causes the menu to return, only to have it disappear after one page refresh.

Going back to previous versions of Devel module and Administration Menu modules solves the problems.

If you have javascript enabled, the admin_menu is loaded dynamically using ajax. So there may be something that is breaking that. Maybe a javascript error or something that prevents the admin_menu request to complete successfully...

Confirm bug ... subscribing.

I'm not getting the white bar replacing it, but the bar will disappear when on an https address but stay visible on http ones. This only began to happen once I upgraded from Drupal 1.10 core to the new 1.11.

Yummy! HTTPS! :)

environment: core 6.11 + admin_menu 6.x-3.x-dev

menu_admin bar is only showed in Administer › Site building › Modules ( path: /?q=admin/build/modules )

On other pages Firebug tells me this:

GET http:// localhost/cms/js/admin_menu/cache/67cac98ae4a7db82e9cce64ba722f3e7 403 Forbidden

where 'http://localhost/cms' is my virtualhost for drupal installation

And I think this is the code that generates that error message:

<form action="/drupal/?q=js/admin_menu/cache/67cac98ae4a7db82e9cce64ba722f3e7
&amp;destination=js%2Fadmin_menu%2Fcache%2F67cac98ae4a7db82e9cce64ba722f3e7"  accept-charset="UTF-8"
 method="post" id="user-login-form">

same problem with 6.11 + admin_menu 6.x-3.x-dev + garland + jquery_update

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?

BAH!!

I fixed my issue with this. I hadn't run update.php after upgrading to the latest dev. I have this working fine now (with cacherouter!)

Edit: It's worth noting that upgrading from 1.x to 3.x incurs the creation of a new cache table, which is why I had the problem.

well, have a look into your "Recent log entries"... probably filled with countless error messages.

/me wonders why error-reporting cannot be configured per-user.

@NikLP: Can you add this info to the other issues as well?

To be completely fair, I'm the only person reporting this fixed as yet, and the other issues all point here. I'll readdress this issue again when there's another response or two :)

very usefull module but it doesn't work always. what a pitty.
(I see the menu on every 20th refresh, maybe more)

I run the update.php and it's still works only sometimes.

environment: core 6.11 + admin_menu 6.x-3.x-dev
same issue in IE8, Chrome, FireFox 3.0.10 .

I will try tomorrow to test it on drupal 6.12

@tommytom: You are running a development snapshot of admin_menu 3.x. If you want a stable module, just install 1.x (dev snapshot being the most stable).

Drupal core has nothing to do with this issue. 6.12 won't make a difference. If you could export your phpinfo() into a text file and attach it here, that would be great.

I installed the version 6.x-1.x in it works perfectly all the time :)

Better title.

But as soon as people see that, they'll go away and run update.php and never come back to comment on the issue! :)

I have been having the same problem with this since the introduction of the cacherouter... I still use dev version: admin_menu-3.0x-dev-[2009-03-29] and do not have any issues with it. (I believe that was the release before the cacherouter was implemented) I just tested the 3.x-dev version as of [2009-05-09] on my "sandbox site" running garland as the theme and can still report as having the same issue of the admin menu disappearing. I did notice that the menu will appear right after clearing the "cache" in performance but will disappear if a ctrl+r / refresh is done. The ONLY time the menu will appear on a regular basis, is when navigating to /admin/build/modules (but this is obviously because that path does an automatic flush of the menu cache through Drupal itself...)

So, I have nothing to really help with at this point, other than to mention the change from the black coloring to red/maroon threw me for a loop... lol I wasn't expecting that! (I personally liked the black, but I'm not overly picky) :)

Hope this gets fixed soon! This module ROCKS!!

Dunno if it will help or not, but here are some of my stats:
Drupal: 6.10
Apache: 2.2.11 (Unix)
PHP: 5.2.9
MySQL: 5.1.30
Browser: Firefox 3.1b2

If you're using cache router, you will need to check that the permissions are correctly set on whatever directory the cache files are stored in.

They need to be writable by your http process (usually apache or something).

ok, re-opening. :(

@philsward: So is it working without Cache Router?

Well, I don't even have cache router installed... I didn't even know what it was until about 30 seconds ago... I just thought it was some part of drupal that the admin menu was tapping into...

SO, No, I have not had cache router installed AT ALL which is probably why I have been having issues...

I guess at this point, my proposal is to do one of three things, either degrade gracefully if cache router isn't installed, post a BIG MESSAGE stating that cache router needs to be installed OR, make admin menu dependent on cache router...

I guess I get to install cache router on my sandbox and see what happens!

:)

@philsward: It was you who mentioned cacherouter in the first place:

I have been having the same problem with this since the introduction of the cacherouter

Cache Router is not required at all and you should not install it. Please clarify what you really meant in #19. If you can, the complete output of phpinfo() might help us further.

Put

phpinfo();

into a temporary file /test.php

Then, invoke that file on your Drupal site, i.e. http://example.com/test.php

Save the output into a file with a renamed suffix (.html.txt) and attach that here.

Sorry about the 'cacherouter' thing... My memory doesn't serve me as well as it used to... :P

What I was referring to, was not the cacherouter, BUT, the introduction of:
#345984 by markus_petrux, sun: Added client-side caching of administration menu.
Attention: A new era of Drupal user experience starts here. This is the very
first issue of a series of improvements targeting plain awesomeness.

I'm thinking that has something to do with it all... SO, scrub the entire cacherouter thing... (now I feel stupid.. :p )

@philsward: It should not make it better, but just out of curiosity (because I don't have a better idea), could you try the patch in #424960: Latest cache updates result in scrambled output ?

Additionally, if that site is publicly accessible, and you can create a user for me and/or markus_petrux, then use my contact form on d.o to send me login data, please.

Saying "you should not install it" about cache router is like saying it's a bad module, which isn't the case. If you're using cache router AND you're having problems with admin_menu, try disabling the cache router module (probably by commenting out stuff you added to settings.php) and then getting admin_menu to work. If admin_menu works without cache router but re-enabling that module causes you problems, it's likely that there is an issue with file permissions on your cache folder (assuming you're using "file" mode). I'm not sure if this would be indicated in watchdog or not, however.

Ok, after doing a few "browser" tests, I have found that the latest dev (2009-05-09) is working fine in IE7, FF 3.0.10, FF 3.5b4 and it was sort of working on chrome, I need to test it some more, but it was NOT working in FF 3.1b2 Apparently, that is where I have been having most of my issues... (feeling a bit dumb at this point...) SO, It looks like I need to decide on updating my browser to the latest beta and loose the "gmail manager" addon, or stay on an older build of admin menu... As far as I am concerned... My issue is resolved... thx for your patience with me on this...

This problem has nothing to do with update.php per se.

I did quite a bit of testing. Menu shows up fine when you open the browser and go to the site for the first time. As soon as you reload the page the menu goes away. However, when I hit "Empty Cache" it comes back - till the next reload. So association with update.php is merely a symptom because it refreshes cache.

Interestingly enough the problem shows up on one of my sites but not another - but both are running off the same server and codebase. Perhaps theming issue, but I am not sure where to look. I am testing in Chrome.

@dkruglyak My point about update.php was that if you haven't run it, the module will *definitely* not work, as the cache tables won't exist. If *after* you've run update.php it still doesn't work, *then* it isn't related to that, but it's a necessary step to get the module working now that it employs a caching method.

@dkruglyak: If you try with Firefox and Firebug console enabled, can you see the ajax request for the admin_menu? If so, may be the problem related to the theme? ...or if not, then the problem may be related to something that happens on the server side.

Firebug console should show you the URL being requested to retrieve the admin menu. If you perform that request manually by putting that URL in the address bar of the browser, how does it look?

I've found a solution for the problem I had with the admin menu disappearing most of the time. I'm using Administration Menu 6.x-3.x-dev.

NB: This only applies to those using the CacheRouter module. If you're not then this will probably not help you and you can stop reading now.

Basically my symptoms were that the Admin menu would often disappear and only a hash value like "1028dffbdc1db6e906ff1c94631c1d37" would appear instead. Sometimes reloading the page would bring it back. Most of the time it wouldn't. If I disabled the cacherouter, the Admin menu would appear without fail. The same symptoms persisted for both APC and Memcached as the Caching Engine.

The problem: admin_menu.module sets two items in the cache with the same $cid, although it does it in separate caching tables (cache_menu, and cache_admin_menu). The cacherouter module doesn't have separate tables with the mechanisms it uses and everything is based on the $cid. So, when retrieving the cached values, it would sometimes 'hit' the correct item, most of the time though it would get the hashed cookie value meant for admin_menu_cache instead.

The solution: Ensure that the two $cid values are different between the two cached items. I did this by changing the cache_get function around line 204 of admin_menu.module

from:
    $cache = cache_get($cid, 'cache_menu');
to:
    $cache = cache_get($cid .":cache_menu", 'cache_menu');

and cache_set around line 217:

from:
    cache_set($cid, $content, 'cache_menu');
to: 
    cache_set($cid .":cache_menu", $content, 'cache_menu');

Hope this helps someone else.

Not sure if related to the full extent of this issue, but certainly related to #6 and #7. Look @ #498754: admin_menu does not show on https (SSL) pages with Secure Pages module

ok, given the info in #34, I'm re-purposing this issue, because that is the only concrete/exact information that makes sense and can most likely be replicated by others. (At least, I know that this may not work with certain cache systems.)

Anything else should go into a separate issue, if not already fixed.

I think that #34 has clearly found the issue, but I don't believe that this part is correct:

The cacherouter module doesn't have separate tables with the mechanisms it uses and everything is based on the $cid. So, when retrieving the cached values, it would sometimes 'hit' the correct item, most of the time though it would get the hashed cookie value meant for admin_menu_cache instead.

If I understand correctly, cacherouter allows you to configure separate bins for different caches. So the solution here would not be to modify admin_menu, it would be to make 'admin_menu' a separate bin. I haven't tested this yet (though I will get to it), but just wanted to point it out.

I'm testing this now; not sure if my recommendation above is correct.

Yeah, I take it back. Setting up different bins with cacherouter doesn't seem to avoid this problem, strangely enough.

Skimming this issue again, I have troubles to find an actual bug report that explains what is going wrong. The only remaining issue seems to be something about CacheRouter, which in turn may be a setup problem totally unrelated to admin_menu.

Please create a new issue with a clear bug report, so we can tackle this more focused.