Closed (fixed)
Project:
ImageField
Version:
6.x-3.7
Component:
User interface
Priority:
Minor
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
9 Feb 2010 at 18:56 UTC
Updated:
10 Mar 2011 at 19:19 UTC
Jump to comment: Most recent file
Comments
Comment #1
quicksketchThis is simply a cache issue. To exactly reproduce:
- Visit a node type that contains an imagefield
- Upload an image.
- Remove that image.
- Upload a different image with the same file name.
Since both the first image and the second image have the same file path, the browser doesn't load the second one. This patch moves some of the code from our normal image display and applies it to the image preview. I've committed it to the 3.x branch.
Comment #2
quicksketchComment #3
quicksketchComment #4
quicksketchTaking this into consideration again, it'd probably be better to use the file uploaded time instead of time(), since it will have the exact same effect but not require the browser to refresh the images every time the node is edited.
Comment #5
Bilmar commentedPatch at #4 applied smoothly but it didn't seem to fix the issue.
Also I experienced the issue with the latest 6.x-3.2
- tested using Garland theme
- uploaded an image
- removed the image
- uploaded a different image with same name
Screencast http://www.screencast.com/users/trupal218/folders/Jing/media/78ee71f9-28...
Also, at 0:03 you can see that when I remove the image, the preview still shows below it. The preview doesn't show below it for the second time an image is removed.
Kindly setting status to Needs Work as the issue still exists.
Please let me know if I may be missing something or if I can provide more info.
Regards
EDIT: sorry i was doing a lot of patching..i think this patch didn't apply smoothly..so the 'patched' version was the same as the latest 6.x-3.2
Comment #6
quicksketchRight, the 3.2 version doesn't contain this fix (you can't change a release once its been created). This change will only be in the 3.3 version when it is released. You can also try out the development version from http://drupal.org/node/96519.
Comment #7
Bilmar commentedhi quicksketch,
sorry I didn't read your comment in #1 as careful as I should have
I saw this issue thread version set to 6.x-3.2 so confused myself
I will be testing the dev version when I get home tonight
many thanks!
Comment #8
Bilmar commentedtested with most recent dev and confirmed the issue is fixed
thanks again
Comment #9
macramole commentedthanks quicksketch !
Comment #11
amfis commentedHi,
i'm still able to reproduce this unwanted behavior.
While creating a new node with imagefield multiple values, it show's wrong preview image, but shows good image inside node. sometimes it works in opposite: shows good preview, but wrong inside node, however, I'm unable to confirm exact steps to reproduce, cause, this occur totally random.
This behavior does not occur while editing already existing node with populated fields.
While investigating I've noticed this:
- I have a few more images already with a same name created by imagefield: 2.jpg which is changed to 2_0.jpg, 2_3.jpg and so on.
- When I upload a new image with the same name 2.jpg to a new node, it gets the last available, already existing image name, that is 2_3.jpg.
- While trying to upload another image with a same name 2.jpg it's name finally gets incremented to 2_4.jpg
- Afterwards, creating another new node, same behavior occur.
To avoid this problem I've started to use filefield_paths module. But it looks like, that imagefield have some issues with determining whether new or renamed image name already exists.
Modules I've using:
CCK: 6.x-2.7
filefield: 6.x-3.7
filefield_paths: 6.x-1.4
imagefield: 6.x-3.7 (and also tried 6.x-3.x-dev)
insert: 6.x-1.0-beta5
Comment #12
amfis commentedComment #13
quicksketchI need exact steps to reproduce. Problem are never random.
Comment #14
amfis commentedRandom occurrence i ment for: "sometimes it works in opposite: shows good preview, but wrong inside node".
I'll try my best to show the problem, maybe screencast would help, like in #5.
Comment #15
amfis commentedOk, so I tested with a fresh Drupal install.
Doing tests, stage after stage by installing various modules which exists in the live site, I was unable to reproduce the behavior described in #11.
This is kind of strange thing.. the live site system uses the same modules as the test Drupal installation.
However there are a few older modules running at the live site. I'll try to upgrade them and see what's happen.
Comment #16
amfis commentedSo I made an live system modules upgrade. The problem persists.
Comment #17
amfis commentedAnd.. there you go, the screencast: http://dev.d3.lt/screencast/imagefield_problem.mov
The development server in this screencast is a synchronized version of a live site.
p.s. I'm still saying the wrong module name.. instead of imagecache ir should be imagefield, because in this screencast there are no imagecache functionality at all.
Comment #18
amfis commentedbump
Comment #19
quicksketchI still need to be able to reproduce this problem on a fresh install in order to fix it. Your video does not seem to be accessible. Please do not bump.
Comment #20
quicksketchThe video does load if I give it long enough so I can see the problem. Could you try disabling FileField Paths and see if the problem goes away? That module does some pretty crazy things.
The way ImageField (or FileField more accurately) determines file names is by attempting to save a file directly into its final location. If a conflict occurs, Drupal automatically appends _x to the file name. ImageField then takes this name and generates a thumbnail at the same path.
Perhaps what's happening here is that when you upload a file, remove it, then upload a different file with the same name, the previous thumbnail is being used because the original thumbnail wasn't removed when the file was removed.
Comment #21
amfis commentedIt could be... but as far as I remember, FileField paths I've started to use, when first wrong thumbnail occurred. I was thinking if files will be in separated directories it could help.. and for some time it did.
Ok, I'll try to disable FileField paths and do more tests.
p.s. the problem with thumbnails in fresh development Drupal install does not occur, but I'll try to do more tests also on that.
Comment #22
quicksketchBased on the lack of reports, I'm assuming that FileField Paths was responsible for this problem, as it's not reproducible on a clean install by myself either.
Comment #23
sansui commentedNot sure if I should re-open this, but I have a live site using 6.x-3.7 that is also experiencing intermittent "stale" imagefield_thumbs files.
We were not using filefield_paths, although I have since installed it to see if it would solve the issue (does not solve preview, seemed to fix final image sometimes?).
The users on this site have a very similar filenaming scheme for many of their images, like B.JPG, BB.JPG, BBB.JPG etc, and most of the time drupal correctly appends a modifier like B_16.JPG, B_17.JPG, but occasionally a thumbnail get stuck from an old node's uploads.
I have been trying to reliably reproduce this, but find it difficult. Sometimes it works properly, sometimes it doesn't.
With filefield paths installed and configured to use node id, the final thumbnail will show the correct thumbnail, but the preview before node save will often show a stale thumbnail.
Edit: I think I can reproduce now.
Upload file B.JPG.
Save Node
Delete B.JPG
Upload alternate B.JPG - imagefield_thumb now shows old thumbnail instead of new one
Save Node - imagefield_thumb shows either new thumbnail or old thumbnail (after installing filefield paths)
Comment #24
sansui commentedSo it seems to me that the thumbnails are not being removed when the images are deleted?
Comment #25
quicksketchThanks Sansui, I'll try this out next time I'm working on ImageField.
Comment #26
sansui commentedActually, I think I might be having this problem with filefield/swfupload. I'm using swfupload for bulk image uploading, and I incorrectly thought it used imagefield... but it's a widget for filefield.
I tested an installation with imagefield 3.9 and could not reproduce stale thumbnails, so I retract my previous report! Sorry about that.
Comment #27
quicksketchBack to closed then. Thanks for the followup.