Images being created in the wrong folder

** DELETED - mis-posted **

I have the same situation here. Its simply not working. Its not creating the directory path and thus the preview is breaking

Same here. Having problems on a remote server, I’ve tried on a new fresh local install (ubuntu intrepid) of drupal 6.9 with imagecache 6.x-2.0-beta6 and beta8. Imagecache don’t work at all. The imagecache folder is not created in the drupal home directory (no « files » folder) nither in sites/default/files (wich is the settings in the filesysteme preference).
The « imagecache_sample.png » is in sites/default/files/ but that’s all.
I tried to change filesystem settings to « private » as I’ve read in the troubleshootings comments¹ with no effects.

Any help welcome.

[1] : http://drupal.org/node/224913

Ok, it seems that I solve my problem enabling simple url in my local apache2 configuration with this manual (for ubuntu) : http://doc.ubuntu-fr.org/drupal

Nemolivier
not everyone speaks french in here

If I understand well you changed this in your .conf file ?

<Directory /var/www/votre_repertoire_drupal>
    AllowOverride all
</Directory>

This is by default in my server but still get the same problem

image is created in the wrong folder
in here
sites\default\files\
instead of
sites\default\files\imagecache\img_thumb

the same problem:

image is created in the wrong folder
in here
sites\default\files\
instead of
sites\default\files\imagecache\img_thumb

here is a solution

admin/build/modules
the "ImageAPI GD2" has to be enabled (maybe its dependency that should be ENFORCED ?)

enabling it made the preset present a preview
(when creating it admin/build/imagecache/#)

and imagefield appears to work correctly
and images are created in the right folder ...

mmm
i have the ImageAPI GD2 enabled, but images are not created in the right folder

I too am having this problem, starting when I moved all the imagecache files from sites/default/files/imagecache to sites/default/files/domain/imagecache. I changed the default system path under site confiuration->file system and cleared the cache but now the path generated to each imagecache file is http://domain.com/sites/default/files/domain/imagecache/thumbnail_tiny/s.... So for some reason "sites/default/files" is being prepended to the filename, even though the correct prefix that I set in my file system settings is also added.

I think we are looking at a nasty bug. Bumping this issue up to critical, I have read different issues people have posted and I think many of them relate to this. I have tested this on different servers and I can confirm that #10 and other is real problems.

It is easy to reproduce by using #10 but there is also other ways to trigger the problem and uninstalling imagecache and installing it again does not fix the problem. The only thing imagecache does is to copy imagecache_sample.png to the root of your files directory. It does not create the imagecache dir when you add a new preset at all. And now is it getting even more strange. Failing to create the imagecache dir does not generate any error messages, but the function creating the preset complain that it is missing. There is actually one way to make imagecache to create the imagecache directory:
1. Create a preset.
2. Go to /admin/reports/status and you will se a message on the top of the page that it created the directory.
3. But still after this imagecache is unable to make the sub directories with the name of the preset.

Have done some more testing and solved one of my problems I detected on one of my oldest Drupal installations. I quickly looked through the source of imagecache.module:

function imagecache_create_url($presetname, $path) {
  $path = _imagecache_strip_file_directory($path);
  return file_create_url(file_directory_path() .'/imagecache/'. $presetname .'/'. $path);
}

So nothing special in here, it uses a standard Drupal API function call (http://api.drupal.org/api/file/includes/file.inc/6). This function does not detect any problem creating the files/directories and Imagecache go ahead and create the presets and store it to the database. If I for example block Apache from writing to the "files" directory, Drupal correctly detect this problem and the preset are not built. So is the problem a Drupal core problem?

Back to one of my old servers that got me started tracing down this problem. In my Drupal files directory I found a old old .htacess file that override the default settings, and no upgrades have changed this during the years:

<IfModule mod_rewrite.c>
  RewriteEngine off
</IfModule>

If mod_rewrite is off you get this strange behavior of Imagecache. I traced this setting all the way back to http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/file.inc?r1=1.74.... Drupal (4.6.x or was it 4.7.x) So all of you that have this problem or simular, pls try and turn off clean URL and test to see if imagecache is working as normal. Not sure why Drupal have not updated/changed this setting during all the updates that have been done to this installation, it might be that the Drupal upgrade script is not supposed to change any of the settings in the file.

Cheers
Steinmb

I am having this issue as well. preview doesn't work, directories are not being created. doesn't work

I am having this issue as well. It started immediately after I upgraded ImageAPI from 6.x-1.3 to 6.x-1.4. Downgrading back to 6.x-1.3 solved the problem, but that's not a good long-term solution.

subscribe

Also having this problem, just download all the updated modules today definitely a new bug

what is everyone's files directory path?

mine is sites/default/files

The imagecache folder exists, but both the sample image and the modified image created by imagecache are located in sites/default/files, instead of the imagecache folder

I created a "sites/default/files/imagecache/teaser_thumb/imagecache_sample.png" file location, because my sample previews are broken (along with everything else) and it says it should be located at "sites/default/files/imagecache/teaser_thumb/imagecache_sample.png?1237525802" although its sending the files to "sites/default/files" on its own, which is obviously wrong.

Anyone have a fix for this?

I tried an earlier release and am having the same problem

I enabled clean urls and it fixed all my problems...I was under the impression that imagecache worked with or without clean urls. I wasted alot of time on this one, lol.

cumber8, I think that your issue must be different from the one we're discussing here. I've had clean URLs enabled from the start, and everything worked until I upgraded Image API.

Same problem here... tried the following methods to solve without success:
* Downgrading ImageAPI to 1.3
* Re enabling clean urls
* calling the files directly at their supposed to be location (in order to create the image cache)

All of my images are getting created at sites/default/files/service_provider & sites/default/files/imagefield_thumbs/service_provider and no image is being created at sites/default/files/imagecache/service_provider_thumbnail (and as wrote b4 when I surf directly that directory with the supposed to be filename I don't get any result and no file is being created)

Just a little clarification, some people wrote that the folders of imagecache are not being created at all, at my system they do get created but not getting populated at all.

Welp! :)

Update to my previous post, tried also the following points with no success:
* Changed the Download method to private
* Used print theme('imagecache', 'service_provider_thumbnail', 'jpowered.jpg', 'just a test image', 'test image'); at node.tpl.php which did print the title and made the right HTML code < img class="imagecache imagecache-service_provider_thumbnail" title="test image" alt="just a test image" src="http://{site_domain}/system/files/imagecache/service_provider_thumbnail/jpowered.jpg"/>

** btw I just noticed the edit option so I do it now, sorry for posting twice :)

***** Last edit - problem solved for me
Frankly I don't know exactly what was the problem but the following steps solved my issue:
1. Uninstalled the modules filefield, imagefield, imageapi, imagecache.
2. Reinstalled them one by one by the order I wrote above, after each install I ran update.php and for imagefield & imagecache I chose the first versions (6001 & 1 respectively), be aware that u will receive lots of db errors from this step cause of the versions selection.
3. Just created a new preset and new field which use file type and image widget and thats it, I got it working.

So I guess that I screwed it up somewhere at the initial installation and it got fixed by those steps.

Cheers!

That fix didn't work for me, anyone have anything else?

Bonjour,
perhaps a new problem
for me the presset image comes in ...files/imagefield_thumbs directory instead of ...files/imagecache/myPressetName/ (but files/imagecache/myPressetName directory exists).
It was Ok with old versions filefield-6.x-3.0-alpha7, $imageapi-6.x-1.3, imagefield-6.x-3.0-alpha4,
but no more with new version of all these modules. Even when creating a new content type with a new field (file/image). But there is a lot of changes there.
Could not it come from that modifications? That directory imagefield_thumbs did not exist before.
Waiting for news
All the best

OK, in local I could see that problem is mine. When I reinstalled I did not reinstalled imageAPI GD2.
(thanked to troubleshooting imageCache document, http://drupal.org/node/224913 , I could identify that I had nothing in site configuration/imageAPI).
Silly of me

I have been having the same issue, and have been since late last year (I posted about the issue then).

I have two presets, Thumbnails and Node_View

I have updated to the latest version of all associated modules, and core, and here's what is happening:

browser looks for image here:
Thumbnails - /sites/default/files/imagecache/Thumbnail/boats/6NCUA707-1.jpg
Node_View - /sites/default/files/boats/6NCUA707-1.jpg

image is actually here:
Thumbnails - /sites/default/files/imagefield_thumbs/boats/6NCUA707-1.jpg
Node_View - /sites/default/files/boats/6NCUA707-1.jpg

Don't know if that helps.
Dan

Same problem here too. This is what I did and it worked! I've been working on this problem for a whole week. All I did was download the ImageAPI module and activate ImageAPI and ImageAPI G2. This will direct the files to the correct folder.

I, and likely others, already have these enabled.

Also having these issue. I tried uninstalling and reinstalling all of the modules six ways from Sunday, no go. It just seems like the cached version of the image can't be created. I tried adjusting the permissions of the cache folder as was suggested in the comments here: http://mustardseedmedia.com/podcast/episode16

I even thought it might be because I was uploading files that had space in the names, but nope.

really would love to get this working.

I am having the same problem. Imagecache is dumping images into the 'files' directory instead of into the 'files/imagecache/[preset]' directory. While it does create the 'files/imagecache' directory, it does not create the 'files/imagecahce/[preset]' directory despite supplying that filepath when the image is later called.

I've been searching for a solution to this for days as well, to no avail.. Clean url's on, imageapi with GD2 installed. Been through the troubleshooting page. New installation, in sub directory. Domain pointing directly at the Drupal folder. Transliteration module in place and working, so I know the file names are not the problem. mod_rewrite properly installed as far as I can tell. Exactly like on other servers.

I have this working on other installations, at least I believe I do. I'm afraid to change any images elsewhere though in case the same issue shows up on other installations as well.

When I create a new preset, and add a scale action, it shows the Drupal preview drop with scaled properly. When I add another action, it bombs out and the preview doesn't load. I then find images in the /files folder.

Oddly, I am able to make a proper preset for a much smaller thumbnail size, with its files right where they belong in /files/imagecache/mypreset The preset I'm trying to create is 800 wide. The one that works is only 80.

I believe I've been through all my upload limit settings and they should accommodate my images.

Another odd thing is I had no tmp folder, although I have the path /tmp set for it in Drupal. I made one, but it doesn't seem to have anything to do with what's going on. My logged error (see below) refers to a tmp folder that doesn't exist. The error shows up the same what whether my hand made tmp directory is in place or not. I've tried creating the /tmp in server root, Drupal root, and /files, but it is ignored.

I'm happy to provide any other information and test - whatever it takes to fix this.

Oh... and my logged error looks like this:

Type: imagecache
Date Sunday, April 12, 2009 - 22:48
User : mylogin
Location: [http cut to prevent link]//www.mydomain.com/sites/mydomain.com/files/imagecache/slideshow_display imagecache_sample.png?1239612495
Referrer: http://www.mydomain.com/admin/build/imagecache/2
Message: ImageCache already generating: sites/mydomain.com/files/imagecache/slideshow_display/imagecache_sample.png, Lock file: /tmp/slideshow_displayimagecache_sample.png.
Severity: notice
Hostname: my server IP
Operations:

Thanks!

I am having this problem as well -- the files are being uploaded (and the thumb images created for display on the edit page) but no files are being created for the presets inside the imagecache folder. All files/folders are 777, the tmp folder is 777, the php.ini limit is very high (and I've never had any imagecache problems on this server with D5), and I am stumped.

Setting the file system to private works, but is wrong for my site for many other reasons.

Update: I am chipping away at this.

First of all, I take back what I said about having one preset that worked and one that didn't. As soon as I flushed the one I had it went away and I had nothing until I resolved the following:

I solved my tmp directory problem. Imagecache seems to want it in sites/files, so that's where I've left it. I tested that together with every combination of .htaccess "RewriteBase /" (on, off, and subdirectory name) and settings.php " #$base_url = 'http://www.leiwailaniphotography.com'; // NO trailing slash!" possibilities.

For my Drupal installation to work I must have:
- .htaccess base: RewriteBase /
- settingsl.php base: commented out (#$base_url...)
- File system path: sites/mydomain.com/files

For Imagecache to work at all I must have:
- Temporary directory: sites/liawailaniphotography.com/files/tmp

My php.ini still says upload_tmp_dir = /tmp, but Drupal didn't seem to see it there, even when I had my Temporary directory set at /tmp. I've left a file there in case Drupal wants it at some point, but Imagecache only wants it in the files directory. It doesn't seem to care where the files directory is, though. I accidentally created an extra files directory in Drupal root like in D5 when I was messing around with the path settings and Imagecache did as well with it there as it does with it in sites/mydomain.com/files The tmp file has to be 775 and not 755 as I saw suggested somewhere.

.htaccess in my files directory contains this and only this:
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options +FollowSymLinks

With those settings, after re-creating (not just re-saving) my presets and flushing everything I could find to flush, I was able to create one preset that works, again the smaller images, and one preset that only works for one image and not the other. I've only tried two images so far. Cached files for the image that's working now show up where they belong in /files/imagecache/respectivepresets and the broken image shows only a lock file at files/tmp/my_presetLfilename.jpg If I delete the lock and reload my page (views slideshow in a block on the page) the lock comes back.

My error message is exactly the same as it was except now it's reporting errors for my uploaded file instead for the sample.png

So, to recap, I figured out where Imagecache wants my tmp file fixed the permissions on it. I ruled out any possible changes to Drupal root .htaccess and sites/mydomain/setting.php. (I think my php.ini was and is fine too.) and cleaned everything up including old imagecache files.

Now I just have to figure out why some images work and others don't. I thought I had it answered today at one point. I remembered that I've had trouble with any files over 72 dpi, and sure enough, the files I had were 300 dpi. I fixed them and am still having trouble even though everything at least seems to be in its proper place.

Well it sounds like you've made the most progress out of anyone. My hosting provider is looking into this issue as well.

My problem is the same as everyone else: presets aren't able to write to the imagecache directory.

sites/default/files/imagecache = empty

The way I've set up my presets everything should be going straight here:

sites/default/files/imagecache/1thumbs/
sites/default/files/imagecache/2main/
sites/default/files/imagecache/3gallery/

All the large images are dumped here:

sites/default/files

All thumbs are being dumped here:

sites/default/files/imagefield_thumbs/

I've also tried all of the .htaccess workarounds that have been suggested.

If anyone has figured out a good solution please post it! :)

I just committed #366177: Imagecache seems to work only if the file system is set to private which might help with this. Please test the -dev release and see you're still having the same problem.

What versions of PHP are people using?

I'm on PHP 5.2.8 with PHP Memory Limit set to 96M.

I'm afraid to set my filesystem to private in case it affects some other modules. But if that's the only solution I'll give it a go. Or else need to find a different module that has equal functionality.

spangaroo, #366177 deals specifically with getting public file transfers working. please test out the -dev release.

tried latest (6.x-2.x-dev) version, no succes.

configuration:

• clean url's
• one preset (named 'voorbeeld') with one action: resize 400 x 400
• manually created tmp folder under files (drwxrwxr-x)

analysis: the original file is stored in the folder files, no resized version could be found

drewish, thank you for the info.

I figured out how to apply the patch here: http://www.ctcvista.org/node/1252

Via Terminal I got through the first part okay, but then it said there wasn't a "imagecache_ui.pages.inc" file my module directory. (I'm using imagecache-6.x-2.0-beta8.)

So I went to here to get the original file.

I ran the patch and reuploaded the module.

I don't know if I am supposed to uninstall and reinstall anything?

I tried to upload another photo and it's still doing the same thing. Perhaps I didn't patch it correctly and I don't know why "images_ui.pages.inc" wasn't in the original imagecache directory.

Still a bit lost but thank you for your assistance.

Fixed with correct lighttpd rewrite for multisite installation. After debugging I found at least my issue was due to incorrect rewrite rule in lighttpd. I changed it to:

"^/sites/(.*)/files/imagecache/(.*)$" => "/index.php?q=sites/$1/files/imagecache/$2"

(note: added extra sites directory with $1 for specific site)

this worked. so not a bug.

I don't use lighttpd or multisite.

@Kiam, knock it off.

To knock what off?

@Kiam, stop changing the issue name, status, category, etc.

cease and desist.

Why? Don't you change it to something that is not even grammatically correct (Images being created in the wrong folder is not correct, as it should be Images are being created in the wrong folder)?

The maintainer kept the title I set, and I don't know why you should not want a title the maintainer accepted.

1. The original headline is grammatically correct. In this instance, "being created" is a gerund in the passive form.
2. It's always rude to correct other's grammar; nobody likes a pedantic boor.
3. This is not a forum for English grammar and you are interfering with the proper operation of this issue thread.

Now, just stop. Please leave this issue thread alone unless you have something substantive to contribute.

Ohh... I forgot to mention that I did switch to the dev version. That may be what fixed the issue of files landing in the /files directory instead of /files/imagecache for me. I just assumed that it had more to do with getting my tmp folder straightened out.

That dev version wasn't the latest, though. The newest files in that package were April 7. I just installed the newest dev, and its still working.

I still have a preset that won't show any images, but I figure that's a separate problem from this thread.

I'm not sure if this is helpful to anyone but I did manage to get this up and running. Originally I had my Drupal install in a subdirectory. I thought I had correctly configured my .htaccess file, but it was probably wrong.

I did a fresh install. Installed ImageAPI first like everyone said. Ran update.

Installed ImageCache and ImageField next. Ran update.

Added Token. Ran update.

I can't be certain where I went wrong earlier this week. But if you're new to Drupal like me, take your time and it will help out.

One of the things I didn't realize that would have helped a lot sooner is that when you create a new preset, the example preview runs automatically. Since my .htaccess most likely was incorrect the error would have been noticed when the Drupal head didn't show up at 400px width like my preset told him to.

Anyway, good luck to the rest of you and thanks again to drewish and others for their help.

Sorry, I should also mention that I put the new install directly in the ROOT to avoid any confusion.

I also installed CCK and FileField and ran update before trying to fully configure the ImageCache presets.

For what it's worth, my Drupal installation has always been in my root directory.

Additionally, I've recently retrograded to Imagecache 6.x-1.0-alpha2 (removing the old tables and removing other extraneous related material) which works well and without any of the directory issues. This would seem to isolate the Imagecache 6.x-2.x branch as the source of the problem while also discounting .htaccess misconfiguration.

marked #365974: Imagecache presets, preview, etc. will not work at all! as a duplicate.

Same problem here.

I installed imagecache, imageAPI, token and all that. When I create a preset, the druplicon example image is dumped in sites/default/files, a 'imagefield_default_images' is created but stays empty.

I have no mod_rewrite support on this support so clean url's are not enabled.

hmmm, I just updated to the newest releases of Filefield and Imagefield modules to the newest versions and now Imagecache is behaving the same way as before.

There is no preview when I create a new preset that scales the image to 90px.

Anyone else have this issue when upgrading to the latest Filefield and Imagefield? If you have a fix or advice I'd really appreciate it.

I've moved my site to a server that supports mod_rewrite. I enabled clean urls upon which imagecache starts working like it's supposed to. It's a standard single site setup.

@netsensei, glad to hear that you got it sorted out.

I'm starting to think that while Drupal is incredibly powerful, it really has some quirky behavior at times. But maybe it's just operator error.

Last night I used SSH to update and the recent releases of Filefield and Imagefield. I didn't disable, just rm -r the folders from the sites/all/modules folder and unzipped tar -zxvf the newer versions in their place. Then I ran update. After that is where I lost my links. I fear that I have to go and reinstall Imagecache and ImageAPI to reset everything.

marked #438010: ImageCache mangles URLS intermittently as a duplicate of this.

I just stood up a new Drupal 6 testbed, with mod_rewrite and cleanurls, with latest modules and had the same problem. Turns out I didn't have the ImageAPI GD2 module enabled. I enabled both ImageAPI GD2 and ImageAPI ImageMagick (probably don't need the latter) and ImageCache now works. Maybe that will work for you...

Hello @all,

I've the same issue. It just came up, if i named the preset name with underscores. Without underscores it works for me.
I've installed Pathauto, Filefield Path and Imagecache Module. First it works fine, after update its broken.

tomtom122, your issue is actually #437098-7: Unneeded node_load in theme_imagecache_formatter

Any more thoughts on this? I really need to figure this out for a client. I uninstalled the associated modules, reinstalled and it's still not working.

Something I noticed with the preview:

I have the file system set up to save to sites/default/files

The imagecache sample is placed here when I enable the module: sites/default/files
But imagecache is looking for it here when I'm creating a preset: sites/default/files/imagecache/thumbnail/
(thumbnail being the name of the preset)

...really need some help. I'll put up a bounty of $25 via paypal for a fix.

I am using 6x 2.0 beta 9 now
Dan

AgentD, looks like it's looking in the right place. Did you enable both ImageAPI and an ImageAPI toolkit like GD? Do you have any error messages in your log fileswatchdog logs?

Had everything enabled.

I bit the bullet and rebuilt everything, took a long time....but now it's working.

Thanks for taking some time to reply.
Dan

Are you still using ImageMagick or are you on ImageAPI GD2? I bit the bullet as well, and did a fresh install of everything.... problem is.... didn't help. I'm getting the same error still.

It seems setting the tmp directory as a location inside the files directory (sites/default/files/tmp) was the way to go.
I'm on DreamHost and the wiki stated that it's often a good idea for non-root folks to use something they have control over as their tmp directory rather than the php root tmp folder.
I believe there were locks (meaning junk files of probably zero file size) with the names of the previously accessed, now unusable, re-sized images.
I'm assuming that since I can access the new tmp folder I'll be able to either flush it or analyze the problem better if this comes up again.

I love ImacheCache, but there are definitely occasional headaches.

ADDED LATER: This did sort of solve the issue, but I'm stuck clearing the tmp folder from time to time. Not sure what to do next.

I'm not sure if this has anything to do with #371195: Images being created in the wrong folder as well, but I'm experiencing a similar problem with a multi-site install.

On my default site, imagecache works as expected.
On any sub-domain, the preset images do not get created by requesting the URL of the preset.

So for image.jpg uploaded to the default.com, default.com/sites/default/files/imagecache/preset-1/image.jpg works as expected.

However, for image.jpg uploaded to example.com
example.com/sites/example.com/files/imagecache/preset-1/image.jpg does not work. No images are created. File permissions are correct, as demonstrated by the working hack below.

I've cobbled together a function to create a preset image:

  function ev_create_imagecache_image($presetname, $filepath)
    {
    $preset = imagecache_preset_by_name($presetname);
    if(!$preset)
      return false;

    $dst = imagecache_create_path($preset['presetname'], $filepath);
    if(is_file($dst))
      return true;

    return imagecache_build_derivative($preset['actions'], $filepath, $dst);
    }

And, in my template file where I want to show the image, I've added this code

      $base_url = base_path() . file_directory_path() . "/imagecache/";
      $a        = pathinfo($img->filepath);
      $filename = $a['filename'] . '.' . $a['extension'];
      
      $t_url = check_url($base_url . 'picture-thumbnail/' . $filename);
      $f_url = check_url($base_url . 'picture-fullsize/' . $filename);

      ev_create_imagecache_image('picture-thumbnail', $img->filepath);
      ev_create_imagecache_image('picture-fullsize', $img->filepath);

Now, example.com/sites/example.com/files/imagecache/preset-1/image.jpg exists.

If this is due to misconfiguration on my part, my apologies for wasting a post on this matter :)

Bravo re Giorgo! Enabling the other module solved the problem for me!

I too have this problem on a multi-site install. Original domain works perfectly. The added domain has no folders being created.

UPDATE: Apparently this issue has been around for a long time and still exists to this date. I have a FIX! Check this thread http://drupal.org/node/536596

Clean install or imagecache-6.x-2.0-beta9.tar.gz under Drupal 6.13 facts:

1. An imagecache directory is created in sites/default/files

2. A imagecache_sample.png is created in sites/default/files (Shouldn't this be in ../imagecache?)

3a. When creating a new preset, sub directories in sites/default/files/imagecache are not being created.
Apache log: File does not exist: /var/www/domain.com/beta/sites/default/files/imagecache/test, referer: http://domain.com/admin/build/imagecache/1

3b. When editing a preset, the Preview image (imagecache_sample.png) is a dead link. (Related to #2?)
http://domain.com/sites/default/files/imagecache/thumbnail/imagecache_sa...

4. Disabling the module and then uninstalling produces the following error in watchdog log three (3) times.
Location http://domain.com/admin/build/modules/uninstall/confirm
Referrer http://domain.com/admin/build/modules/uninstall/confirm
Message uasort() [function.uasort]: The argument should be an array in /var/www/domain.com/beta/sites/all/modules/imagecache/imagecache.module on line 259.

@#72: The solution you suggest has been already reported in #366177-19: Imagecache seems to work only if the file system is set to private.

I'm getting paths generated of this form:

http://DOMAIN/files/imagefield_thumbssites/DOMAIN/files/FILENAME.gif
and:

http://DOMAIN/sites/DOMAIN/files/sites/DOMAIN_ALIAS/files/FILENAME.jpg

I have DOMAIN as one of my multisites, and DOMAIN_ALIAS is a symlink in the sites folder to DOMAIN.

More odd behavior.

I've got a ImageCache preset to convert the original image (1600x1200) to 800x600 and then create a thumb of 150x130. The images are uploaded in a new content type via file upload field.

The images are being saved in.

../files/imagecache/800x600/
../files/imagecache/thumb/

AND duplicates in:

../files/
../files/imagefield_thumbs/

Any idea what is going on here?

If you are uploading the image using the upload field, then you are uploading a file on your computer; in that case the upload field cannot know if the image you upload is the same of an already existing image, and that is the reason of having duplicate images.

Not quite sure I understand your explanation. How else would you go about uploading and using presets to alter the images then?

It's working. Just saving duplicates in other dirs.

I mean that when you upload a file from your computer, the upload field doesn't verify if there is already another file with the same content; the upload field simply copy the files in the directory where it saves them.

Ok so basically you're saying that the upload field creates one copy, and then ImageCache creates it own?

This isn't every efficient. Isn't there a way to disable the upload file save? Or perhaps my way is incorrect?

It seems that the upload field is creating a copy of the files when it should use the files created by ImageCache; I don't know the reason of doing that, but for sure there is a good reason.

I'll add my name to the long list of people having this issue.

In my case I upgraded from D5 to D6, had to move my files directory - now it's looking in the wrong place for the images.

Hmm...
We're getting a lot of reports of 'images gone' after 5->6 upgrade.
Is it that people are moving their files directory?
Is this actually a step required by upgrade?

It's not required by the 5->6 upgrade, no - sites/[xxx]/files is still the recommended file_directory_path AFAIK.

I'm experiencing this issue as well with a non-standard file_directory_path too ... we have moved it since the site was installed, though it has always been a Drupal 6 site. (We had a good reason to move it - something to do with Google not indexing the file contents due to Drupal's robots.txt rules. But that's by the bye.)

Just a stab in the dark, but I'm guessing either there's something hardcoded involving the file_directory_path location, or there's some cacheing going on ... it could be due to whatever ImageCache is doing with menus, but I think that's unlikely because I've cleared the menu_cache table a whole bunch of times. Maybe IC derives some kind of path from the file_directory_path when it's installed, and doesn't want to let go of it?

Sorry I'm not more familiar with IC, and can't spare the time to look right now...

I doubt it is related to anything hard-coded. I for one have my 'files' dir in my root dir, not the ../sites/all/files as it defaults in 6.x

Do the core upgrade docs (assuming we have some now) say you should move files from /files to /sites/yadayada?

Becuase if people do that, I doubt that the database entries that say 'image for image node X is HERE' will follow.

Correct, changing your files dir on a previous installation will break the links. My point was that it doesn't matter where the files dir is located.

For what it's worth, when we moved the files folder I went through the database and updated each reference to match. (Not a job for the faint of heart.)

However, I'm no longer sure moving the folder is related to the issue - gdoteof doesn't mention this in his original post. I think I may have been heading down a blind alley there.

"its looking for [...] sites/default/files/imagecache/image_cover/14096808371d7825afc8150fk0.jpg
but the file exists at: sites/default/files/images/cover/14096808371d7825afc8150fk0.jpg"

I can only get imagecache to work when my files directory is set to /sites/domain.com/files

When I move the files directory anywhere else, imagecache does not work.

#89 was solved by clearing all caches.

After moving a site from sites/default to sites/SUBDOMAIN.COM, I had to do a search-and-replace on the "files" table to update the paths to the original images before they'd show up again...

UPDATE files SET filepath = REPLACE(filepath, 'sites/default', 'sites/SUBDOMAIN.COM');

subscribing

#91 - that's a normal consequence of moving the files from one folder to another, and not specifically to do with this issue. Probably useful to note though :)

Subscribing

Got this problem as well, at least, I think it's related. And I fixed it, somehow.

You know the preview image of the drupal head when making a new ImageCache preset?
Well that wasn't showing at first, but as it was my first time working with ImageCache I didn't bother because I didn't know what it should be anyway. Though I discovered fast enough that thumbnails of my actual images didn't show either.

I remember I struggled with this the whole day and fixed it, but now I am making a new website, and I'm having the same problem. And I suck at documenting: I forgot how I fixed it.

I remember I had to check a checkbox somewhere which fixed the whole thing.

I am now comparing both websites to see if I can find what I did... I will let you know when I find it..

subscribe

to #95 Dreamlinker: Probably you have activated the required clean URL

Why would the "clean_url" fix this issue:

Images are saved here sites/default/files/[preset]/image.jpg but expected by imagecache to be in here sites/default/files/imagecache/[preset]/image.jpg

??

and yes, I have it on a brand new site I just installed, never met this issue before. (I did always use clean URLs though)
(I can't activate clean urls on this site just yet, it's a sandbox)

I activated clean URL's anyway, and issue is suddenly gone. Okay then. My bad. :D

My image-cache was working good, but i want it to overwrite the presets, i didn't make new ones i just override them on the settings screen, after that images stop showing up. every time that i upload a pix it gets created on sites/default/files/. I am using Ubertcart so i need to have those pix created in three different folders every time that i upload a product (product_full, product, product_list). It creates all links, but doesn't upload the pics to the right folders. My quick solution is upload every image trough ftp on the folder because the links are created to those folders but images doesn't. any help???

Simply fix this by Enable GD2
https://drupal.org/node/536596

Good luck! :)

@#100 Please read over the forum before posting. This is not helpful. See #8 and follow ups in this forum.

I had this issue as well as an issue of the image not being displayed in a table view using a custom imagecache preset but enabling ImageAPI GD2 seemed to help. I am using imagecache in conjunction with imagefield and ubercart marketplace in D6.19.

In terms of displaying the image in the view, only the alt text was displaying, so it meant the view and imagecache were "kinda" working.

I was stumped with this issue alone. After reading some threads here, and checking my /files, I too noticed that images were being written to the wrong folders. Thanks to this thread, and enabling ImageAPI GD2 it fixed by image display issue, now the images are showing up correctly in my table view. I haven't yet checked whether it will/is writing images to the correct folder, but I will report back if it doesn't.

When I first installed the imagecache module, I didn't know the purpose of the ImageAPI GD2 module so I never enabled it, perhaps, as it was mentioned in earlier posts, it should be made a dependency for ImageCache (required) or at least have an explanation of its purpose.

subscribe

After a lot of problems, i managed to get it to work.

First i created all the folders manually, and chmod them to 777
I left the htaccess file as is, because it was ok
Checked all the settings as mentioned by the above posts.
Then i disabled ImageCache API GD2
Then enabled it again, dan it works.

Because i work on a multisite, i had to add this entry in my settings.php on my subdirectory root :
$conf['file_directory_path'] = 'sites/"subwebsite"/files'

Thanks for all your help

I am using drupal 6.20 with image fupload 6.x-3.0-rc2 to uploads images and imagefield 6.x-3.9 but it appears that imagecache 6.x-2.0-beta10 is dumping the images in the tmp folder instead of dumping them in the correct folder in sites/default/files/imagecache/thumb I have setup the base path in settings.php but this has no effect.

The outcome of each upload is always a red x image missing. I would be very appreciative if somebody can tell me whats up here. My file system I believe is set up correctly File system path: sites/default/files and Temporary directory: tmp

Enabling ImageAPI GD2 fixed my problem nice.

@Road Kill: You could have resolved your problem, but other users in this thread didn't report the problem was resolved.
The report should be closed if the issue is resolved also for the others.

Yes your absolutely correct apologies did not mean to close the thread.

Nice one, garethsprice! #91 was just what I was contemplating for my own conundrum! Nice meeting you at Florida DrupalCamp, btw.

Cheers!
Stephen

image field 6.x.3.2
image cache 6.x.2.0 beta10
image api gd2

Images are created in sites/default/files/imagefield_thumbs folder instead of sites/default/files/imagecache/

I am having the same issue as Sree. All my files are being created in either the files directory or files/imagefield_thumbs. No files are being created in imagecache/*

Edit**

I do see that the Imagecache UI is creating the file in the correct location why i make modifications to my presets. The images are not being created when I upload from an field_image within a content type.

The sample.png should be in the imagecache directory:
imagecache_ui.pages.inc, lines 251 and 257, 'imagecache_sample.png' should be 'imagecache/sample.png'

My details are:
Image cache version : 6.x-1.6
Drupal Version : 6.16
Image cache API version : 6.x-1.6

file system is ok.
clean urls are enable.
image API GD2 is active.
still have problem in image cache.
save at : sites/default/files/
I need my image file in sites/default/files/imagecache
is there any solution for this problem?

@ganesh_c91:
Pls. upgrade to Image_cache, Drupal core, imagefield, Imageapi and filefield first and test again.

Thanks for help steinmb.

I actually DISABLED clean url's and it works for me. This kinda stinks, as clean url's is far and away more preferable for me.

I also have this problem. Unfortunately I have no idea what has caused it, as the site was working fine until early December '11.

What I know is:
* Images are not resized or processed.
* Images are saved in files/ directory and not the image cache directory.
* Disabled all modules in turn that were updated using drush around that time, with no luck.
* Deactivating clean URLs makes image cache work correctly. (not an ideal solution.)

Putting status back to what it was before #112 as this did not fix the problem and, in fact, broke some existing image links.

- Oliver

Tagging as D6 stable release blocker.

Seems there are at least two possible solutions:

1. Get a fresh copy of the Drupal .htaccess file (Rewrite rules have changed and ImageCache requires the .htaccess from newer versions of Drupal)

2. Use GD instead of ImageMagik.

Removing release blocker.

I, too, was having this problem. RewriteEngine was on in my .htaccess file. The following modules were installed and enabled: FileField, ImageField, IMCE Image, ImageAPI, ImageAPI GD2, ImageCache, ImageCache UI. But I had one role that was working correctly. After comparing that roles' permissions against another role whose images were being put into the imagecache folder, I found the difference. In the IMCE profile I just needed to check Browse, Upload, Thumbnails, Delete, and/or Resize for the directory path they were assigned. That fixed it for me. Hope this helps some others.