No directories created by imagecache

I am having the same problem.

No directories created and some rewrite errors in logs.

[Thu Jul 05 15:58:01 2007] [error] [client 127.0.0.1] script '/var/www/index.php' not found or unable to stat, referer: http://localhost/a-kontra/mesto-4-2006-0
[Thu Jul 05 15:59:28 2007] [error] [client 127.0.0.1] File does not exist: /var/www/a-kontra/files/imagecache/product_list/files, referer: http://localhost/a-kontra/products
[Thu Jul 05 15:59:28 2007] [error] [client 127.0.0.1] script '/var/www/index.php' not found or unable to stat, referer: http://localhost/a-kontra/products

(Sorry, I changed the title by mistake...)

Roman

same problem

hmm, similar problem. Shortly after upgrading full site to 5.3 and installing a working imagecache, we got the issue where fluch images no longer created the appropriate directories

It did get so far as to delete the appropriate directoried, but did not recreate them - and if it can delete them, than the perms are correct. I'm digging through code now trying to see the order of events.

So digging through this, I'm still not sure why the directories aren't being made. I can pretty much trace it to imagecache_cache not being called.

Also, was curious, is it appropriate to put some filechecking into the theme function:

Currently:

function theme_imagecache($namespace, $path, $alt = '', $title = '', $attributes = NULL) {
  $attributes = drupal_attributes($attributes);
  $imagecache_path = file_create_url(file_directory_path() .'/imagecache/'. $namespace .'/'. $path);
  return '<img src="'. $imagecache_path .'" alt="'. check_plain($alt) .'" title="'. check_plain($title) .'" '. $attributes .' />';
}

Potentially:

function theme_imagecache($namespace, $path, $alt = '', $title = '', $attributes = NULL) {
  $attributes = drupal_attributes($attributes);
  $imagecache_path = file_create_url(file_directory_path() .'/imagecache/'. $namespace .'/'. $path);
  if (is_file($imagecache_path)) {
    return '<img src="'. $imagecache_path .'" alt="'. check_plain($alt) .'" title="'. check_plain($title) .'" '. $attributes .' />';
  }
  else {
    return 'The requested image is unavailable.';
    }
}

This is redundant and hopefully unnecessary but helpful in my debugging.

Just an update to anyone else using running into this, last night I rolled through the past three 5.x versions of imagecache with the same issue, so I'm gonna say its a server setting we are missing. Once I figure out what it is I'll post back, then we can build a check into the requirements function.

subscribing...

I have the same issue. I've created my imagecache presets (thumbnail and display) and created a "photo" type content type which has an "image" cck field. I've configured this image cck field to store the images in a "photos" directory inside my configured file system path (files/mydomain.com).

I am successfully able to create "photo" type nodes and the uploaded images are stored in "files/mydomain.com/photos". However, imagecache did not create any directories. Even when I created the missing directories, it didn't create the thumbnail and display files for me. From looking at the generated source code, I can see that it is trying to use the URL "http://www.mydomain.com/files/mydomain.com/imagecache/thumbnail/files/my...". I don't think it is handling the file system path correctly - there is no need for "files/mydomain.com" to appear in the image directory path twice.

So to summarise, it's not creating the directories for me. When I create the directories manually (with correct permissions) the images still don't get created. The directory path it is using to link to the images seems wrong.

If you need any more info, please let me know.

Cheers,
Stella

Well, actually, that is the correct path. imagecache generates a path with the domain in it for some other issue I can't remember right now. The issue still remains that for some reason it isn't generating (recursively) the proper directories.

I'm not even cerain tthat it _isn't_generating the images, as they are generated (and later destroyed) in the tmp directory. If the path doesn't exist for them to be moved to, then they _may_ just be being deleted at the end of the cycle.

Still working.

Fair enough, I just thought it strange the domain name was repeated twice and thought it might be part of the problem.

The "files/mydomain.com/imagecache/thumbnail/files/mydomain.com/photos/" directory definitely exists. The entire directory tree is owned by the web server user. It was user writable, but I've made it group writable too just in case. So the permission on each sub dir is "drwxrwxr-x".

The "/tmp" directory is definitely writable by the web server. For each image upload, I see one new temporary file created there. My web server is "lighttpd" in case that makes any difference. I'm also using PHP-5.

My .htaccess in files/mydomain.com has the standard entry:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

I'm now using the latest version of the code from CVS, and drupal-5.2 but still no luck.

Cheers,
Stella

So here comes so info that makes absolutely no sense to me, but I'm now just posting new info as I find it:

1) So, I made a test install and confirmed that on a base install imagecache works fine cck, imagefield, and imagecache are the only things enabled - works fine. That rules out server settings, as I thought above.

2) Going back to the site with issues, multisite the actual files directory is files/sitename I rolled it back to be just file imagecache does not work.

3) I then disabled our theme, going back to bluemarine.... and imagecache works - it generates the proper directories and everything.

4) So, leaving bluemarine on I changed files back to files/sitename ... and imagecache stops working.

conclusions: Something in the combination of calling the imagecache theme function && having nested directories... is borking directory generation.

I'm thinking that the filepath being passed in the theme is inherent to the old files/sitename, from the db.
so I will next try that with the custom theme.

I've tried doing some further investigation but haven't had much look. I've even tried adding print debug statements to imagecache_cache() but it never seems to be called. Well at least my debug msgs are never printed. I'm probably going about this the wrong way but if there's anything you want me to look at, just let me know.

Cheers,
Stella

WOuld you mind just testing the situation I've laid out above on a test site. i.e. Copy your current site and change your theme to bluemarine and your files path from files/mydomain.com to just plain files and see if imagecache begins working.

I'll keep looking. thanks.

ok - update, so forget anything I said about theme... tracked down that and its irrelevant.

Tried a base install with a nested files directory with no issues. Now I'm just trying to reproduce on localhost. I think we've solved things for our prduction site be relocating files/mysite to files and leaving any legacy images ther. It's not ideal, but working for now.

Meanwhile I'm trying to figure out duplication instructions for this one.

I changed my file path to just be "files" while leaving the imagefield sub dir to be "photos" but it still didn't work. I then modified the imagefield so it didn't use a sub dir, but that didn't fix the problem either. I tried creating the "imagecache" directory in the hope that the module would then be able to create the sub directories, but to no avail.

From looking at the code, I think it's the imagecache_cache function that creates the directories and files. I've tried adding debug messages here but they never appear. When exactly is this function called?

Cheers,
Stella

Yes, imagecache_cache() creates the directories and files. It is called when an image doesn't already exist.

The idea goes like that:

• Drupal, caused by the .htaccess file in the base directory, delivers all files directly by Apache when they actually exist. If a request URL doesn't point to an existing file, Drupal is called with the path instead.
• By registering the same Drupal path that the result file path will also be (namely: "[file-directory-path]/imagecache"), imagecache catches requests to the image in the case the image doesn't yet exist.
• When the request is caught, imagecache_cache() is called, and that function is supposed to create the appropriate directory (if necessary) and the transformed file.
• Next time when the same URL is requested, Apache recognizes that the generated file is already there, and delivers it without invoking Drupal at all.

This is the reason that imagecache only works with clean URLs and public downloads, because the Drupal request URL that is caught by imagecache needs to look exactly like the real URL of the file.

If imagecache_cache() is not called, it means that there is already a file in that place. If no such file exists, it likely means that the debugging statements were not done correctly.

Looking at the code, I don't notice any dependency on a plain "files" directory (anything is done with file_directory_path() which returns the configured file path). If imagecache_cache() is called, there are three conditions that cause directories (and, in consequence, files) *not* to be created:

• If the image at the original location doesn't exist. (The original location is probably something like "files/images/image.png".) In that case, a Drupal 404 page is returned instead of the image.
• If the destination path is already an existing file. (The destination path would be "files/images/imagecache/presetname/files/images/image.png".) In that case, a watchdog error with the message "There were problems generating an image from %image using imagecache preset %preset." will be created.
• If the temporary path (for generating the image) is already an existing file. (The temporary path would be something like "/tmp/presetnameimage.png".) In that case, the same watchdog message as mentioned above will be created.
• Or, if something goes wrong while creating the directory. In that case, a watchdog error with the message "Could not create destination: %dir" will be created.

I hope that should easy finding the bug. I'm not testing it out for myself currently, don't know when I'll find time for that. In any case, great work on tracking it down, keep on!

I tried writing debug error msgs to the drupal log using drupal_set_message("my msg", "error"); as the first thing in the imagecache_cache() func. The original image definitely does exist and I can access it directly in my browser. I'm now pretty sure that it is a lighttpd & drupal thing.

First off, when I try to access a preset version of the image itself, I get a 404 error in my browser and both the image and directories are not created. The 404 error is just "404 - Not Found" which is coming from the web server. It is not a drupal 404 error. I'm using "lighttpd 1.4.13 (ssl) (Aug 9 2007 15:47:53)". It doesn't use .htaccess files, which should be okay as I'm using drupal 5.2 and rewrite is on. However, it doesn't support hooking into a 404 error handler. It was added in version 1.4.15 but apparently only really works properly in the svn version. Obviously I'm reluctant to upgrade my web server, with code that hasn't been released yet, in case I introduce security risks or break my other drupal sites, which are all happily working away.

As soon as a new lighttpd release comes out, I'll test it out to see if it solves this issue for me. Until then, it looks like I won't be able to use the imagecache module. Fingers crossed it won't be long til the next release!

Cheers,
Stella

Yes, that's definitely a lighttp issue then. If you give less on the "cache" aspect of imagecache and just need the image operations, you can give one of the patches at http://drupal.org/node/141127 a try - they make imagecache work with private downloads as well, and might work for you.

Maybe related..., when renaming the preset namespace, everything in the imagecache folder gets deleted and after that no new directories (for the new names) are created.

Hi all,
Out of my experiments the preset name MUST be lower case.
By having it as mixed case the generated URL does not exactly match the path in the file system and imagecache_cache fails in retrieving the requested preset_id.
Hope it helps

Same problem here. No directories created, no errors reported. Could it be an Apache problem? Any suggestions?

same problem here as well:

- my teaser spits out:

<img title="" alt="" src="http://liquid5/files/imagecache/portfolio_teaser/files/screenshots/puggit.jpg"/> 

where portfolio_teaser is the name of my preset.

But no imagecache folder exists.

the file files/puggit.jpg does exist

not sure what's missing here??

i deleted files/.htaccess and imagecache is now working

I think it could be some kind of Apache permissions problem.
Are they some requirements in the .htaccess, files/.htaccess, sites/default/config.php files to get this work?
I have Drupal installed in a subdirectory of my domain. Any special configuration is needed this way?

- I have created from 0 a new Drupal 5.2 installation in my root domain, so I can access from http://domain/
- Enabled the Clean Urls, created directory files and give 777 permissions. (also run cron.php and disable config.php permissions)
- Installed and enabled only the modules CCK, imagefield and imagecache.
- Configured one imagecache namespace, with a scale 10x10 option.
- Added a field image to the Page content.
- Created one page with one image.

(I am sure that my image toolkit GD2 is working ok)

Result:

Only one image with the original dimensions is created in files. No subdirectories.

I think this is a critical bug, or is urgently needed a documentation for the neccesary modifications to the .htaccess file.

Anybody following this steps get it work?

I get where is the problem!!

The image only is created when it has to be viewed, I mean, when the node is displayed, outside the admin section.

I was checking the files directory directly after the save action in the administration and nothing ocurs.

I think this kind of notes have to be in the readme file.

Hope this help.

I was also having all of these problems. I tried making the directories by hand and setting the permissions to 777. No luck. The trick for me was under "File system" admin settings. Make sure that the files are set to "public" AND the temporary directory is "tmp" with no slashes (by default it is "/tmp").

The solution was originally reported here:
http://drupal.org/node/166848

i just wanted to say that this happens to me too. the behavior i noticed is rather erratic, sometimes the folders are created under /files/imagecache but no images are created. and sometimes no folders are created at all. :( none of the "fixes" suggested here have worked for me. :( so any other help would be very much appreciated.

my setup is a lighttpd box with php and mysql. i am, actually, using imagecache with ubercart. and yes, i have clean-urls enabled.

thanks! :)

Marking closed. Open a new thread as this one has gotten muddy. Mine was a miscalling of imagecache in the theme compunded with a server setting, another one was a misconfigured .htaccess, and a few others look unsolved. If you reopen make sure to provide:

Reproducing instructions.
Your files settings are public
Your toolkit is working.

Thanks

I just resolved this issue for myself. I spent too much time on it.
Hinted by other posts here I've checked Drupal logs (which showed nothing) and Apache error log. The latter showed:

/var/www/rymland.org/drupal/files/.htaccess: Option FollowSymLinks not allowed here, referer: http://www.rymland.org/gallery

The problem was some Apache configuration which prevented from the .htaccess in the files dir from being processed ok. I had some directive which prevented it.
Fixed that, restarted apache - and the land is peaceful again!
--
Boaz Rymland
PHP therapist
Linnovate

none of this works for me either.

Drupal 5.3
I have setup imagecache
I have kept the .htaccess files as in the readme
I have clean urls enabled
In file system there is file and tmp.

The very first time i logged in and upload a photo it works.

As a user, if I click delete and upload, the image is delted byt I cannot then upload another picture

If I change a preset and click save changes, the images are flushed, and again no directories are created.

I am so very lost.

Any suggestions?

Hi,

I also have the same problem with imagecache where, in laymen terms, all the images that I upload to the imagecache field of an Ubercart Product node would show up blank. The symptoms are as follows:

1- The image file are missing in the "files/imagecache" folder.
2- Apache log file shows "File does not exist" error messages each time I upload an image.
3- The problem is only on my existing site, but not in a brand new Drupal 5.3 site.
4- If I try to flush or update the Imagecache's presets, then the "imagecache/preset" folder of that preset would just disappear.

I had spent the last 2 weeks on the ubercart site looking for a solution until I tried the same query today on drupal.org! If only I woulda-woulda-shoulda ... from day one. :)

Anyway, the problem is in the "files/.htaccess" file. This file in my existing site contains the following:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
<IfModule mod_rewrite.c>
  RewriteEngine off
</IfModule>

The "working" file contains the following:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

The fix it to replaced my site's "files/.htaccess" file with the one from a working site. Now all the images uploaded to the imagecache field shows up!! YEAH!!! :)

I had never modified this file before, so I do not know who or what added these extra "ifmodule" lines. At this point, I don't care! I can now test Ubercart and learn how to implement it on my site!!!

Cheers!!

-w

look the file temporal settings in drupal admin settings. We were crazy looking for the non creating directory problem and it was as simple as changing /files for files (without slash).

this might help someone with this issue, you can try it, no harm: http://drupal.org/node/280144#comment-1128800

it´s very important also the cck content template. If you don´t use the correct field the image seems to be not created. Try unactivating the template and using the default to see if the problem is here.