Problem with Administer -> Settings -> Cache Settings. When I turn caching on, Logo Tool has problems if I've specified anything other than Normal Mode.
When set to normal, and caching on, things are fine.
But I would like to have random logos on every page except the home page which is a set logo, so I made that work "node|logo.jpg", but when set to "Specified and Random" and caching turned on, the logo doesn't display and if I reload the page there's a Fatal error in drupal_get_path_alias in line 166.
I only had 4 path aliases set, so to test if they were some how involved I removed them, but the disappearing logos when caching is on, persisted.
When I set it to Random logos, the Fatal Error is instead at line 126, file_scan_directory.
In both cases it says the function is undefined.
I've checked the permissions of my directories and find no problems.
Can logotool.module be updated so it works with caching enabled while in Specified and Random mode?
Thanks, Drew.
Comments
Comment #1
pobster commentedHi, sorry to disappoint - but I don't believe it'll ever work with caching... Caching stores the entire page for 'quick' viewing (ie. without having to rebuild the page from every darkened corner of Drupal) images however, are still linked to the original image. This makes complete sense, as an image *should* be static and so the path to it will always a. be the same and b. actually *be* the image. Now of course Logotool follows a. as the path is always logotool/logo, but well... b... hmmm... this is a problem... logotool/logo isn't an image, it's code which 'supplies' an image. As a bad example, it's a file server perhaps (?) I don't know if that'll clarify or not mind ;o) Anyways, with caching on you can't access some functions from Drupal simply because Drupal doesn't 'expect' to have to use them. The functions Logotool are trying to access aren't Logotool functions at all, they're from the Drupal API and it's caching which is preventing it from finding them.
I don't think I can help here, unless someone can suggest otherwise? I understand in some circumstances that you can use hook_menu with !$may_cache to handle things which can't be cached, but I really seriously doubt it'll help here... Biggest problem is, last time I looked - absolutely NO documentation on how that's handled anyway...
Pobster
Comment #2
Bairnsfather commentedThanks for looking in to this Pobster! I could see your module was doing some fancy foot work in always pushing out a "logotool/logo" as the url to the logo, but I didn't know what happened in terms of caching. I figured the image wasn't compressed with the cached page and inserted in my db since it seems better to assume the image would still be at the same path. But as you can tell I didn't know what happened behind the scenes. Now I understand, the cached page is "confused" in to thinking your module *is* the image. Ok. Hm, I too looked for the function you named in the 3 API compilations and it wasn't found.
It sounds like that function may cause part of the page to not be cached, or replaced as it's being sent and that part *is* updated when the server sends it out, thus most of the page is cached, but that one part isn't. Sounds handy.
Could your logotool forward the real path to the image? Instead of making drupal think it *is* the image? As you can tell I'm just wondering...with very little php knowledge.
Thanks for your time. -Drew
Comment #3
pobster commentedhttp://api.drupal.org/api/4.7/function/file_scan_directory
http://api.drupal.org/api/4.7/function/drupal_get_path_alias
See, annoyingly both the above functions exist - it just seems you can't access them when you're using the cache! I'm afraid if I knew of a way round this, I'd have done it by now :o( As I have sites myself which would definitely benefit from using the cache... I'm afraid this really isn't something I can fix unless I can either have some proper caching documentation or perhaps even just look at the code of another Drupal module which does something comparable? Neither exist... At the moment anyway... Sorry...
Pobster
Comment #4
Bairnsfather commentedHa, no reason to feel sorry, I'm just glad you wrote what you did!
Anyway, since I know this, "if I knew of a way round this, I'd have done it by now" I have peace of mind. :-)
Comment #5
pobster commentedFixed in newest dev version hoorah!
http://drupal.org/node/133749
Pobster
Comment #6
pobster commented