When uploading new image of previously deleted image with the same name, the old thumbnail is displayed.
| Project: | ImageCache |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Hi,
This is a quirky situation whereby an image is uploaded, say with the name image77.jpg. If that image is then deleted and a new image uploaded with the exact same name but quite a different image, then while the full page version of the image is correct, thumbnails aren't.
This originally occured in version 5.1 so I upgraded but it is still occurring. I have the following in mymodule_nodeapi()
case 'delete':
if($node->type=="image") {
imagecache_preset_flush('thumbnail_preset');
}
I thought this might get rid of any rogue thumbnails, but still I keep getting the thumbnail for the deleted image appearing.
This may well be a problem with the upload module or file.inc but I thought I'd see if anyone else has experienced anything like this.

#1
Running into the same problem...
I suspect this is a similar issue #356429: empty IMG tags shown in views where image field is empty just at an earlier stage of diagnosis
I suspect I need to peek into the database to figure out what is happening.
#2
I eventually did this in mymodule_nodeapi $op = 'update', which solved the problem:
$real_path = db_result(db_query("SELECT f.filepath FROM {files} f LEFT JOIN {content_type_image} i ON f.fid=i.field_image_image_fid WHERE i.nid=%d", $node->nid));imagecache_image_flush($real_path);
#3
I have the same problem. Deleting old and uploading new original images is no problem, but the images in imagecache/ stay the same. It should be really basic thing to delete or update images in the imagecache folders, right? I haven't tried the above snippet yet, but i feel that i should not be playing around with code snippets for a function that is so standard.
Does anyone have an idea why this happens?
I use the latest version by the way: 6.x-2.0-beta9.
#4
Subscribing
#5
I think the problem is ajax, deleting the image and then pressing save is a working process but deleting an image and reuploading the same image or at least image with same file name prevents imagecache image being deleted. This needs to work for making revisions. It's a real headache for webmasters too. I get unknown action when I try to flush cache afterwards and cache is not flushed. I have to go in and manually remove the cache folder before things work properly again. Thanks ..
#6
Is a fix for this being considered? It causes havok for my site sometimes and yet when I delete all files in image cache every thing works fine again. Why not simply flush the entire cache every time content is deleted if content contains imagefield?
#7
I'm having the same issue, which is causing my ubercart install to display the wrong product images.
Here's how you can replicate this bug:
1. Create a node which has a cck imagefield in it. Upload test.jpg and save the node.
2. Visit the node page so that the imagecache thumb is produced.
3. Delete the node.
4. Create another node and upload test.jpg.
5. Visit this new nodes page and you'll notice a stale imagecache thumb.
Here's another way you can replicate this bug:
1. Create a node which has a cck imagefield in it. Upload test.jpg and save the node.
2. Visit the node page so that the imagecache thumb is produced.
3. Remove the image associated with the imagefield and save the node.
4. Edit the same node again, and upload a different picture called test.jpg and save the node.
5. Visit this new nodes page and you'll notice a stale imagecache thumb.
Here's a way you CAN NOT replicate this bug:
1. Create a node which has a cck imagefield in it. Upload test.jpg and save the node.
2. Visit the node page so that the imagecache thumb is produced.
3. Remove the image associated with the imagefield and re-upload another image with the same name.
4. Save the node.
5. Visit this new nodes page and you'll notice that the imagecache is updated. This is because imagefield will re-name the second image uploaded to test_0.jpg thus making it a new name for the image/imagecache.
Solutions for this:
Imagecache will need to delete the cache files it creates when an image is updated or deleted. I would assume this could be done by implementing hook_nodeapi. Otherwise it will have to implement a different storage system based off FID instead of filename.
I consider this a fairly critical bug with imagecache, although most users will never notice it as it would happen rarely. But I'm sure if it was easier to come across, more people would be complaining.
#8
I'm not sure but I think after setting imagefield_thumbs folder to 777 and flushing cache my problems have gone. Not 100% sure though, need to test it some more.
#9
Flushing your cache will solve the problem.
But we can't tell the end users (and perhaps they wont have permissions) to flush their imagecache every time they upload a new image. This isn't practical and there is a bug which causes this problem which should be resolved. It's also a huge burden resource wise as each imagecache thumb will need to be re-created.
#10
I'm using imagecache fairly long time and now described issue happend on my site. There are about a few thousands of imagecached images. So I can't just flush it all.
#11
This small bash-script has helped me to delete all imagecached files which has no source at the time. I guess it can be used by cron to prevent risk of wrong image show.
find files/imagecache/thumb/i -type f -printf '%f\n' | while read link; do [ -e "files/i/$link" ] || rm "files/imagecache/thumb/i/$link"; doneHere:
files/i - source directory
files/imagecache/thumb/i - imagecache directory
#12
Subscribing my scenario is second one in #7 except name of image is irrelevant
Here's another way you can replicate this bug:
1. Create a node which has a cck imagefield in it. Upload test.jpg and save the node.
2. Visit the node page so that the imagecache thumb is produced.
3. Remove the image associated with the imagefield and save the node.
4. Edit the same node again, and upload a different picture called test.jpg and save the node.
5. Visit this new nodes page and you'll notice a stale imagecache thumb.
#13
There's no way that imagecache can know that the files changed via a hook because Drupal 6 doesn't have a standard notification mechanism for file events. In D7 there's hook_file_update() or hook_file_delete() that can tell us about changes.
If someone wants to roll a patch that compares the timestamp of the source file and the cached image and expires the cached image if it's older than the source file I'd be happy to review it.
#14
@drewish: hook_file_update() and hook_file_delete() isn't used by Drupal Core in 6.x - but they're actually used by Filefield and Imagefield and it might be a good idea to have imagecache support those hooks - then everyone wanting to tell imagecache that a file has been updated or changed could invoke the hooks and we would have a pretty standard way of talking between files that works very well with Drupal 7.
I'm adding a patch for that.
#15
#16
voxpelli, not sure what you're rolling that against because I've already got a imagecache_file_delete() function. Update to HEAD and see if that takes care of it or if we really need to implement update as well.
#17
Sorry - my mistake - had missed that it has been added in the latest version - should've checked.
#18
Glad to see some eyes on this. I noticed a new imagecache was released a couple days ago and
"# #447402 by drewish: Not removing derivates for deleted filefield images." was in there.
http://drupal.org/node/447402
Is this the same issue as drewish has mentioned.
Thanks for all the work on this issue.