This is targeted specifically for Windows and IIS 6.0 or 7.0, but it works for Apache to.

Probably the first instant problem everyone will experience is this:

The selected file xxx.JPG could not be uploaded. The file is not a known image format.

It doesn’t actually matter what file you try to upload if you’re using IIS or Apache you will get this error. The fix is to edit the file in

/includes/image.inc, and change line 117 from:

if (!is_file($file)) {

to:

if (!is_file($file) && !is_uploaded_file($file)) {

I recon we all think Drupal is great, but I wasn’t happy when it took me three days to solve the imagecache problem. If you’re using IIS and you’ve done everything you can think of you could skip to the end, but this post might make a useful check list to see that you’ve done everything necessary to get imagecache working.

The problem I’m having is that when I upload an image to include in a node I get the following:

* A thumbnail of my image is created and stored in the directory sites/default/files/imagefield_thumbs – which to me means that the imagefile module is working ok.

* An unadjusted copy of my original .jpg file is uploaded to the directory sites/default/files

imagefile module appears to be working fine

I can see that the directory sites/default/files/imagecache has been created, however the contents of this directory are completely empty of both files and folders – so it would seem from this apart from creating a directory the imagecache module isn’t really doing a lot.

When I browse my homepage I can see the node being displayed (and if I use IE I can see an empty image container) which shows that there is code in there to display an image however it’s pointing to a directory of a path that doesn’t exist and to an image that isn’t there:

sites/default/files/imagecache/fullsize/IMG_0119.JPG

IE shows an empty image container

The fix

Firstly as of this post 24/09/09 I’m using the very latest versions of these modules – they are:

Drupal 6.14
imageapi-6.x-1.6.tar.gz
imagecache-6.x-2.0-beta10.tar.gz
imagefield-6.x-3.1.tar.gz

It is my aim that by the end of this post I will have found a way around this problem by getting to the bottom of what’s going on and I hope that it will work for you to:

BAM!

Working fine with unadjusted image (ie no image operations assigned)

Ok, the first thing I tried was to remove the selection of any filter type. This means rather that select my own created preset filter type I called ‘fullsize’ and ‘thumbnail’ which have filter actions applied to them, I simply selected Image from the drop down list and not any of my own created stuff like ‘fullsize’ or ‘thumbnail’ which have image operations assigned to it. This means that the HTML now points to:  /sites/default/files/IMG_0119.JPG

Which is fair enough, but then it means the HTML is now pointing to an image that I know is there because of imagefile and not because imagecache is now working.

My next step is to create a new preset filter type for imagecache arbitrarily called ‘test’ – this should create a directory called test that has the path /sites/default/files/imagecache/test where I assume all images created by the imagecache module with the filter called ‘test’ are stored.

Ok – Bingo!

I created a new preset filter type ‘test’ I didn’t apply any actions to it, but the directory ‘test’ was not created. Furthermore there is a link to Preview the non-existant directory with the url:

/sites/default/files/imagecache/test/imagecache_sample.png?1253793901

Ok, so ‘test’ is not created but I do see an image called ‘imagecache_sample.png’ which is good but it’s in my file upload root directory: sites/default/files/imagecache_sample.png not sites/default/files/imagecache/test/imagecache_sample.png

To check this further I’m going to delete this sample image and then try my test again just to make sure exactly when the imagecache_sample.png file is created.

Yup. The sample image file is created as soon as I click on the ‘Save Preset’ button – but why does it not create the correct directory imagecache/test and save it there? Could it be a folder permissions thing and just not throwing up an error?

Maybe – I’ll just go and confirm that to.

Ok. My files folder has read and write permissions set but NOT ‘modify’ I’ve just added that permission, I’ll run the test again creating a new preset filter type called ‘test2′ – again with no actions applied to it.

No. Yet again there is no new directory created called test2, but again, the imagecache_sample.png is written to sites/default/files.

I’ve just gone and updated my version of PHP from 5.2.8 to 5.2.11 – Still doesn’t help. I’ve also created a tmp directory in my Drupal 6.14 root which is fully writable – still doesn’t work.

I’ve just noticed that after running Cron I can see that GD Library is listed twice! I don’t know if this is important or not but at this stage I’m treating absolutely everything as suspicious and seeing that GD library is used by imagecache to create the images I’m going to now put GD library under the microscope.

Okay, having just disabled the GD libraries, downloaded ImageMagick for the Win32 platform from here I’m still getting the same problems – no fullsize image being created, the thumbnail (which seems to be created by imagefile in imagefile_thumb) works fine – but then that’s imagefile and NOT imagecache – so yet again it seems that after even more bleeding out the eyeballs hasn’t paid off.

I’ve spent days on this, I visited just about every website on Earth, I’ve updated my PHP, path directories, modules. I’ve hacked away and done my best to find a solution and just at the moment I must admit to being at a complete loss.

Right I’m back again!

It’s been another entire day on this and after a bit of encouragement from the comment section I’m sticking with this problem until it’s solved. Sorry that this is turning out to be such a long post but it’ll be worth it when imagecache is working!

Firstly YES I have read the troubleshooting guide which you can find here: To save you looking I’ve copied all the salient points here (with a bit of my added commentary) This is what the author of ImageCache has to say: (my comments are in bold italics)

What can go wrong?

No images in the imagecache directory

First, don’t jump the gun and think there is something wrong. Imagecache only creates its images on demand. This means that when you create an imagecache profile, the imagecache directory {}/files/imagecache/{profilename}/ starts off empty.

(No it doesn’t it starts off not existing, it never gets created – ever and nothing ever starts working either, my directories are completely writable as well.)

Files directory

Go to Administer > Site configuration > File system. Are the file system path and temporary directory writable by Drupal? Is the download method public?

(Done that, checked it, double checked it and absolutely confirmed and yes they have ‘method public’)

Rewrite

Obviously rewriting needs to work. And clean URL’s. Does rewriting work in your files directory? Is .htaccess allowed?

(I’m running Drupal on my own Windows 2003 Server with IIS 6.0 as the web server. I am also using the full version of Helicon’s ISAPI_Rewrite 3.)

Try this:

1. Upload a file. After that http://www.example.com/files/file.jpg should return the file. And http://www.example.com/files/nonexistantfile.jpg should present a Drupal “page not found” error.
2. If you get an error from Apache instead of Drupal, rewriting is not working. Check (with your host) whether .htaccess is allowed.
3. If not then this part from the Drupal .htaccess file should be copied to the Apache configuration file:
   RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

4. If .htaccess is allowed make sure the original Drupal .htaccess file, including the exact lines above, exists in the main Drupal directory. And secondly make sure the .htaccess file under your files directory contains exactly these two lines (no more no less):
   SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options +FollowSymlinks

   Note for sites upgraded from Drupal 4.7: Older versions of Drupal wrote an extra line to the .htaccess file disabling mod_rewrite which is no longer necessary but will interfere with ImageCache.Of course both files should be readable by Apache.

5. If it still doesn’t work, and you are using Drupal in a subdirectory, uncomment and modify the RewriteBase.
   RewriteBase /<your subdirectory here>


Hummm. The bit above looks interesting… I’m using IIS 6.0 on a Windws 2003 Server. The .htaccess file is only for Apache Servers. It looks as though I’m definately onto something here. I just did a google for ‘imagecache ISAPI_rewrite’ and I found a post – ONE post in the World that says something useful. If you are using IIS 6.0 as your web server you will want to take a look at this site here:

http://www.helicontech.com/forum/forum_posts-TID-9726.htm

Did I say this site was for Apache too? Well after moving my site to a Linux server – everything I have written above didn’t help me – until i completely deleted the file .htaccess from my \sites\default\files completely – and then bOOM everything worked perfectly. BUT please remember this post was written for Windows and IIS users only.

Again, for my own clarification and ease of access I have included the salient points; ‘zeman’ on the helicontech website has this to say…

“Editing the nested .htaccess in “sites/default/files” and added the default rules worked for me as well but I had to change the final rule to accommodate the new location of .htaccess. Using Rewrite 3.”

RewriteRule ^(.*)$ /index.php?q=sites/default/files/$1 [L,QSA]

[It] Might be worth adding this to the Drupal instructions page.” (No kidding!)

What zeman is saying above here is that Drupal’s original .htaccess file should be added to the contents of the .htaccess file in the location sites/default/files -  also including his modification “to accommodate the new location of .htaccess”

So what this means now is that the .htaccess file in sites/default/files should look like this:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options +FollowSymLinks

#This is the code copied from the .htaccess in Drupal’s root directory tacked on in here.

RewriteEngine onRewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteCond %{REQUEST_URI} !=/favicon.ico

#The path below is no longer valid because this .htaccess file is in sites/default/files#RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]#So we simply change it to include the path to our images folder

RewriteRule ^(.*)$ /index.php?q=sites/default/files/$1 [L,QSA]

If you are using Ionic’s IIRF use this code in your IsapiRewrite4.ini file

RewriteCond %{HTTP_HOST} ^(caspianit\.co\.uk).*$ [I]RedirectRule ^/(.*)$ http://www.caspianit.co.uk/$1 [I,R=301]RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule ^/(.*)$ /index.php/$1 [L]

This is the most promising snippet of code I have seen in days. I’m going to reboot my server just to be on the Uber safe side make a cup of tea and try it out. Fingers crossed…

IT WORKS!! YESSSSS!!! HAHAHAHAHAHAHAHAH……

Three days of bleeding out the eyeballs and I’ve finally got it working! A huge thank you to ‘zeman’ and everyone who has provided insights on this problem. Quite frankly I’m amazed there aren’t thousands of people with this issue. It’s probably because most people are using Apache and not IIS. Well it may be 2:05am but I think I’m probably too excited to sleep now.

Just a quick footnote if yours is still not working just remember to create a new node and upload your image first – before trying to access it with http://yourdomain.com/files/image.jpg just go to your homepage normally and get imagecache to create the file first!

All the best

Sci-Fi Si.