Imagecache no longer creating directory and working after upgrade

After deleting the imagecache tables and reinstalling I find that all my imagecache directories are now absent and have been deleted.

When I put the url for a non-existent image in the imagecache directory into the browser I get a blank screen, not an apache or drupal error screen. For any other directory I get a Drupal page not found.

I also continue to get a display for an image that was previously there using an imagecache directory in the url but which is no longer existent. ie this continues to display an image: sites/default/files/imagecache/location_image/picture.jpg and it appears to be resized.

I've tried deleting the local /files .htaccess file, deleting the imagecache directory itself, clearing the cache and I still get the nonexistent imagecache image and a blank screen when no image is present. Note that when I put sites/default/files/non_existent_folder/location_image/picture.jpg into the browser I get a Drupal Page not found screen but sites/default/files/imagecache/non_existent_folder/picture.jpg, I get a blank screen.

This is something weird and I don't even know if has to do with the Imagecache module but it certainly must be related to why the module is not working. Currently Imagecache is not creating the imagecache directory at all. Has my server got some kind of 'bug' now with respect to this folder?

Anyway I've relocated the files folder elsewhere and retried everything in the new location but still with no luck. There are no error messages in the log or anything and the imagecache folder no longer creates. I've been through all the issues in the troubleshooting page and everything is in order: file system, urlrewrites etc. It's as if Imagecache doesn't exist. I do wish there were more error messages indicating where the module has run into problems so they can be debugged quickly.

With the files in the new location Imagecache is spluttering back to life but now I am getting the following ftp error on one of the preset's directories:

CWD location_image
Response: 550 Can't change directory to location_image: No such file or directory
Error: Failed to retrieve directory listing

The new imagecache directory is behaving in the same way as the old one as follows:

When I put files/non_existent_folder/location_image/picture.jpg into the browser I get a Drupal Page not found screen but files/imagecache/non_existent_folder/picture.jpg, I get a blank screen.

This is probably not an Imagecache problem but something to do with the server. -Or is it. This directory is created by Imagecache, so what is happening here?

I probably selected 'won't fix' too soon.

What appears to have happened is that Imagecache has worked briefly, created some directories, converted some presets and then something has happened to the status of the imagecache directory and no further processing happens through imagecache.

Thanks very much for the response.

- delete files/imagecache altogether. If you cannot, that's a bad start
Directories delete OK, they just don't appear to be created.

- check your admin - file system settings and ensure Drupal thinks the files dir is writable (tell us the exact chmod if poss)
Drupal produces no error messages. chmod is 777 because I set it that way. It that OT?

- visit your imagecache settings, preset, and save a preset. About then a dir with that name should be created. Check its perms.
No messages indicating a created dir

Try a new, simpler preset and see if it comes down to a single action you are trying to use.
Created a new preset with only one action. This works but there is no associated directory -must be on the fly.

if the username the webserver runs under changed at some point
I'm not sure what you mean by this. Surely if I reinstall Imagecache after this happens then it shouldn't matter.

It is correct that you don't get a 404, imagecache doesn't play that.
So the imagecache directory will never display Page not found for images that don't exist within it. This is normal behaviour?

Some time later:

The directory for the preset created while writing comment #5 has since appeared. Whether this delay is due to Imagecache or my ftp client (FileZilla) I have no idea.

Initially cached images in this directory worked, but after adding a second action to the preset no longer did it work and then again when I removed the extra action. On later viewing the preset directory I can see that the cached images that were previously there are there no longer.

So it appears that Imagecache works for a while when a new preset is created and then stops.

After more experimentation I have removed the rounded corner script that I've been inserting into the url (which previously worked) and all my imagecache presets are working, HOWEVER, there is as yet no sign that any of the directories are being created and there is no imagecache directory at this point so for all I know images are being created on the fly. Maybe my ftp client is slow to detect them, who knows but I can't see an imagecache directory even after I disconnect and reconnect from ftp.

Thanks dman,

Yes, it's normal that imagecache handles its own requests, not the big Drupal 404 page. It only works by disabling that handler in the first place. if the file is not found, THEN imagecache tries to resolve the request. whatever is happening for you can't go 404 again, although it's supposed to be able to return a 404.jpg image - set in the prefs

That's good to know.

Anyway, I come back the following day and all the preset directories are present and imagecache images are working. I have temporarily disabled the third party rounded corner script until further notice. What I have learnt from this is that while modules are in the alpha and beta stages of development it is advisable to: backup database before doing updates and check output of all updated modules. The Drupal 6 Update Status module is a great enhancement but there is a hazard in just anybody doing updates and they really need to be monitored in case things go wrong. Consequently I am disabling the module for this site and only enabling it when I am ready to check updates and so no other admin people get to see the persistent warning messages.

Thanks very much for your time and I hope this thread is of use to other people. While I have no idea what the problem was I can now consider this issue fixed.

Just a note: I've re-enabled the rounded corner script and it is working alongside imagecache, so this cannot have been the problem. Like I hinted previously the problem may have been caused by some idiosyncratic mix and match of upgraded modules, since these images in my current usage rely on Imagecache, ImageAPI and FileField. I did notice that the FileField module had become disabled. Since I am not the only person working on the site I cannot account for everything that might have led to that.

There are a LOT of moving parts going on there, and a dozen permutations of versions as well. So yes, anything could be possible.

Yes, that would be the case.

Only now do you mention that you are using an unknown rounded corners action

This is only added to the url at the end of the process, prior to sending, in node.tpl.php. It would in no way affect the creation of presets, or even cached images.

Many GUI FTP progs do cache their results, so that's a handicap sometimes.

I am using FileZilla and will have to think that, from what I am seeing, the results of imagecache directory creation is not being shown immediately, even though when I create a directory manually it can be seen instantly.

Thanks very much for your attention. There is no need to respond to this. I think it is complete.

Further enlightenment...

The third party rounded corner function WAS playing a key role in the malfunction of imagecache even though it was only applied to the final output. I have since created an admin switch to turn this function off and on. I have found that for each new image it has to be turned off so that the image can be loaded once which means the function IS interfering with the creation of the cached image. After the cached image has been created then everything displays no problem.

The rounded corner function rewrites the urls as follows:
themes/mytheme/roundedcorners.php?src=imagecache/my_preset/my_picture.jpg

Obviously this was preventing the creation of the cached image. It shouldn't prevent the creation of the directory but I suppose if no images process then there is no need for the directory to be created.

I added the rounded corner script early on in the site development and new images were uploaded successfully after that (but maybe new presets weren't created). It was only after the upgrade that the script started to get in the way.

I'll gladly post the script somewhere but what is the imagecache actions queue? I used this: http://www.assemblysys.com/dataServices/php_roundedCorners.php

I suspect that what you envision is probably impossible. To get anything other than 'lumpy' coloured images you need a script that can detect the colours used in the image and then create a smooth transition between the image and the background. If you think about it this is the only way to create a rounded border without somehow editing/reading the image.

The script only uses one image which means you only have to recreate the one image using a colour that fits your background. If you want a border you just incorporate that into the image.

Any complex on-the-fly script is only going to take up extra bandwidth. The best solution is probably a script that, like imagecache, processes the image and saves it WITH rounded corners after having 'read' the image and any other configurations such as borders or such that you want to add to it.

Whatever is done, it will be an imagecache process, so it only has to run once, and yes, may be a little intensive and will of course be reading the image and writing a new result.

It would probably have to integrate into the imagecache process or at least leave the rounded image in the same place with the same name as the original.

Anyway I'm sure someone has written a script somewhere, but as with you, I haven't currently got the motivation or the indepth knowledge of GD, so in the meantime I'll stick with this simple script.

All the best.

You should probably work through all the imagecache install instructions all over again. Check also that none of the auxiliary modules have been disabled. In my case it was Imagefield or Filefield (can't remember). I am not totally convinced that my problems were caused entirely by the rounded corners script.

When I got imagecache going again it took me at least a day and I do not have a list of all the things that I did. It has taught me not to use update status and keep my modules up to date because most new release modules have bugs. It's only when a module has been in use for a while that it becomes stable. Not only do you have the module workings itself there are also the myriad interactions between different modules and your situation is likely to be quite different from mine if cron is not working too.