Imagecache stopped working

From your preview image, it looks like your files are not in your /files directory. How could that be?
"sites/all/imagecache" is wrong wrong.
Check the file settings in the admin-config.
Also look at the logs (reports) . There you will see the incorrect requests being made for files that cannot be created, and this will provide some clues.

are you sure you are using sites/all/files?

I ask because drupal sets sites/default/files during install unless you've altered along the way for some reason.

Look at the file, it's not the same as the root one at all.
It's a security control measure that prevents arbitrarily user-uploaded files from being executed on your system (where they could do all sorts of damage). It's not a problem, it's normal behaviour - at least it is when the files directory is set to a normal sites/{sitename}/files place.

Running it with sites/all/files may possibly work, but is at least odd and unsupported and not recommended. Just don't, it may be interacting in very unhelpful ways.
Running it with sites/all - without files, as per the screenshot and what you say above - is just a recipe for pain.

It's usually safe to assume that the reason something is behaving in unexpected ways is because something unexpected has been done to the system. In this case, it's hard to guess what else has been changed outside of the normal expectations.

Well, it sure as hell shouldn't be, ad if it is, would be enough to cause all sorts of confusion.
Delete the damn thing. The file upload system will replace it with a different .htaccess file. Don't delete that one.

I had the same problem. I changed the name of my preset (there was an underscore in it, as in medium_pictures) to simply "a" and the issue went away. I started seeing the preview image and everything. Why this happens I don't know.

I fixed my problem by patching up the imageApi module with this patch. I'm not sure if it would solve yours, but it's worth a try:

http://drupal.org/node/540486#comment-2616056

I was having trouble with imagecache not creating images or folders on my server (windows server 2003 w/ iis6) and for the life of me could not figure out what the hell was going on with it. It would delete (flush) just fine but wouldn't create anything except the imagecache_sample.png and only in the /sites/default/files folder. It wouldn't give me a preview of my presets using the sample png though.

Went all through the code all day trying to figure out what was going on and did several searches online throughout the day to see if anyone else was having this problem.

I finally found this thread and decided to give the file system change from public to private a try.

Lo and behold it started creating everything and displaying the images properly.

But this isn't a good or consistent solution. On another install on the same server the opposite is in effect. I can't view imagecache images if the file system is set to private. The only difference between installs is that one is Drupal 6.17 (needs to be set to private) and the other is an Aquios install (needs to be set to public). In the Aquios install it has to remain public because it won't show imagecache images or allow users to download files (gets access denied message instead) if it's set to private. That's not a huge deal, it all works fine. But it makes me worry that users will not be able to download files on the pure drupal install since it has to be set to private for imagecache to work there.

Is this just some kind of screwed up .htaccess issue or something else? Why should it matter what mode downloads are set to for the file system? While looking through the imagecache code I saw there are functions that are supposed to take that into account to display the images yet on my server they don't.

I've never had any trouble like this on a linux server. Unfortunately I'm stuck with this as that falls into the purveyance or IT and in my company IT and Web are completely separate. T_T

All I can figure is that this has something to do with .htaccess since windows uses ISAPI Rewrite. I think we're using version 2 but I'll have to verify that.

In any case, if that's what the deal is what can I do to fix it? Or is that not it at all?

Any insight would be appreciated.

Thanks in advance (and for reading my rambling...) :D

I am using Drupal 6.17 and I am experiencing the same problem. As soon as I set the download method from "private" to "public" the problem vanishes. Of course, converting to the "public" setting is not desirable ...

It seems the Backup and Migrate-Tool is to blame:

832910 After upgrade from 1.2 to 1.3 I can`t see any uploaded images.

After switching from 6.x-1.3 to 6.x-2.2 everything runs smooth again.

I have the same issue as #11. I tried merzikain's testings and it turned out that for me switching from public to private file downloads made imagecache work again. I have no idea why and I would like to make this work with public file downloads.

The website I'm working on is not built by myself and does not on my own server, so I don't really know all the in's and out's yet...

Upgrading Backup & migrate did not work.

Same here, tried the update to backup and migrate but still no go. My biggest problem is that in private mode it creates images and folders fine but won't let anyone download anything but in public mode people can download but imagecache stops working. It's ridiculous and I can't find a good reason for it. The only other consideration would be some kind of node access issue with the downloading problem but that still doesn't explain why imagecache would work with one mode versus the other.

If you have moved your site or are sharing a database with several codebases for development, try this solution: http://drupal.org/node/160323#comment-253332

I'm using Imagecache 6.x-2.0-beta10
Also am using backup_migrate, but the issue was there prior to installing this module.
Issue seems particularly on Windows server. I have overall spent a few weeks addressing fickle imaging performance. It was solved by others, but indicators of problem, and resolution by modification of imagecache.module is elsewhere and in my post here
http://drupal.org/node/938776.
I am guessing the reason it has not been fixed within distributed modules is that the issue is really to do with the way Windows servers have been set up, but even so, the number of users being effected, and the length of time of issue must be indicative a patch is needed.

This just happened to me. I'm on Backup-Migrate 6.x-2.3, so let's rule that out.

The big change that I know of is PHP 5.3.2-1ubuntu4.5. I have upgraded everything to the newest.
ImageAPI 6.x-1.9
ImageCache 6.x-2.x-dev (2010-Jul-11) v 1.112.2.9 2010/05/26 21:08:58 drewish
Imagecache Canvas Actions 6.x-1.7 (last recommended).

Right now, I am getting a 404 Not found on the Imagecache'd version of the image. Indeed it is not found because ImageCache has apparently not created it. Everything that existed prior to the PHP upgrade works fine, but no new IC images are being created.

#18 fixed this for me ... check the path of the temporary directory in your file system settings.

Mine was a simple fix. I have a multisite configuration with 8 - 10 sites on it. I had my files settings set for each site to "sites/siteX.com/files," where siteX = the individual site folder, and "/tmp" for temporary files. This configuration worked for 6 months or so. When it stopped working, I changed the temporary setting to "sites/siteX.com/tmp" and everything went back to working properly.

I was having a hard time figuring this out. I tried all the suggested fixes for this error. Ultimately #18 above worked with one small change. I had to go up one directory on the "Temporary Path" setting because my site is installed in a sub-directory and not the root on my server. So I changed the temp directory in File System to "../tmp"

subscribing

For another module I've been working on for different site I have this function I found elsewhere:

function user_photos_imagecache_generate($presetname, $filepath) {
  if (!$preset = imagecache_preset_by_name($presetname)) {
    return;
  }
 
  $dst = imagecache_create_path($presetname, $filepath);
 
  if (!file_exists($dst)) {
    imagecache_build_derivative($preset['actions'], $filepath, $dst);
  }
 
  return $dst;
}

I find that if I call that function before my theme('imagecache',blahblahblah) the function generates the image I need. But that alone isn't enough to get it to display. I have to run the results of the theme() function through a str_replace('sites/default','system',$output) to change the link to the Private File System style even though I'm using Public File System. Make NO sense whatsoever but it works for me.

We will be migrating our hosting off of this crap ass windows server as soon as possible so we can go back to a normal system and get rid of all of this hacking crap.

I still have no idea why Imagecache isn't generating the images without that function and even then why I have to change the url to the private fs styled links to show them.

There have been a few issues listed here. If anyone is having this problem still, please start a new issue and explain your situation.

and the problem is......somehow a copy of the root htaccess found its way into sites/all/ ??????

I did the same thing last night - thank goodness for this thread!

I changed the download method to private and it worked, but that wasn't a good enough answer since so many of my previous sites worked without that.

I also had the same issue: a copy of the root .htaccess had managed to copy itself into my sites/all directory.

What a weird thing to happen, but deleting it made imagecache work again as expected.

FYI I ran into this yesterday and found what appears to be an easy solution.

Imagecache mysteriously stopped working with no error messages other than a "page not found" for the derivative images. Just as mysteriously it was working again this morning, and then tonight it stopped again.

After reading this, I went to the file system settings and just clicked "save" without changing anything (it's set to public) and now Imagecache is back!