CACHE_DISABLED; upgrade cache code for D7

Same here

i have this problem too, happens when i login with facebook connect and logout, i go back to front page with this drupal error message.

CACHE_DISABLED is not a constant that is defined in D7, it's a D6 thing.

I don't think that $GLOBALS['conf']['cache'] does anything in D7; pretty sure it was replaced with the page_cache_invoke_hooks setting which can be TRUE or FALSE.

So, the warning reported here should be harmless as it's only incorrectly setting a variable that isn't used, but also highlights that some code that we think is doing something useful is really not.

From reading around, it looks like setting page_cache_invoke_hooks to TRUE stops external caches like Varnish from working, so I don't think we can simply roll a patch that swaps the D6 variable for the D7 equivalent.

The error went away when I set the CACHE_DISABLED to 0. As I read somewhere in the forum.

@neriweaver - that will make the error stop displaying, but the underlying problem is that it seems this block of code was not updated when the D6 version of this module was ported to D7. It looks like the module is trying to force page caching off for some reason at this point in D6 but simply defining CACHE_DISABLED to be zero won't make this behaviour work in D7. So, you can set CACHE_DISABLED to pretty much anything you want and the error will stop appearing but it won't really address the reason why the error was appearing in the first place.

It's trying to disable caching when the user is connected to facebook. This is relevant when user is logged into facebook but anonymous to Drupal, which can happen depending on how you configure fb_user.module (or leave it disabled). This feature of fb.module is less necessary than it once was. So it could go without working and most users would not notice.

I looked for documentation around the CACHE_DISABLED constant going away, but never found any. Thanks thedavidmeister, for the hints.

The right fix is probably to make a settings checkbox i.e. "disable caching when user connected to facebook" and then properly disable caching when that is true.

I realised that what I said is likely wrong! sorry >.<

the page_cache_invoke_hooks variable is actually replacing the aggressive caching setting in D6; D6 has "no page cache", "normal page caching", "aggressive page caching".

as i understand D7 has separate settings for cache on/off and invoke hooks on/off so there are actually now 4 combinations, although I don't know what turning cache off with hooks off would do??

Anyway, this is from the project page of http://drupal.org/project/dynamic_cache:

Technically, you should set the global $conf['cache'] variable to FALSE for D7, or CACHE_DISABLED for D6 (which equals 0) inside of your own module's hook_boot() implementation, however simply setting it to 0 (or false) in either case should work fine.

Ok. Right now the dev branch uses 0 in place of CACHE_DISABLED. (I had already changed that in one place, but missed a second).

I'm leaving this issue here, since I'm not convinced this is exactly right. But also not sure what is exactly right.

I think set it to FALSE instead of 0.

One issue would be that normally, as stated on the dynamic_cache module page, even hook_boot() is too late to disable the page cache; it has to be done in settings.php.

I think a setting is a really good idea. The site that I'm setting up fb on has high enough traffic for it's setup that it really can't handle having page caching off for anonymous Drupal users; the server kind of starts to fall over if I try that.

I didn't find a lot of documentation around how fb module interacts with a site's cache setup.. having it silently disabled it in the fb settings.inc file looked a bit extreme to me, but I don't entirely understand what it is supposed to be doing there.

I think set it to FALSE instead of 0.

Any reason why? Drupal core seems to use a lot of CACHE constants. Some start CACHE_..., others DRUPAL_CACHE_... I can't tell what's what any more, but they are integers.

There's another recent change to modules/fb, where when fb.js triggers a page reload, it uses a POST (not a GET). And that alone should get past Drupal's caching. So I'm hoping that gets around any potential problems here.

Actually, I don't know the reason, but my first module application was denied in one of the rounds of reviews because I used 0 and 1 instead of TRUE and FALSE for something that was boolean. The numbering for cache previously was 0 = off, 1 = on, 2 = very on. I take back what I said. Do whatever, there's not really any good official docs that I could find on the matter anyway.

That said, the best thing would be to try our best to be sure that we don't need to hardcode a disabled cache like this in the first place.

Here is the line of code where the "caching for anonymous users" is set for Drupal core.

Code from http://api.drupal.org/api/drupal/modules%21system%21system.admin.inc/fun...

$cache = variable_get('cache', 0);

This is only good for reading which caching mode you are currently in, not for setting anything for this page view. Happy coding ;)