CCK version: 6.x-2.6
imagefield version: 6.x-3.2
imagefield_crop version: 6.x-1.0-rc1
imagecache version: 6.x-2.0-beta10
permissions for your tmp and files directory. :works fine
download method : public
imagefield configuration : using imagefield_crop widget
expected results:
Image urls should have a timestamp appended to them
// Add a timestamp to the URL to ensure it is immediately updated after editing.
$query_string = '';
if (isset($file['timestamp'])) {
$query_character = (variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC) == FILE_DOWNLOADS_PRIVATE && variable_get('clean_url', '0') == '0') ? '&' : '?';
$query_string = $query_character . $file['timestamp'];
}
Problem:
Url isn't getting the timestamp. The image should be passed into theme_imagefield_image so that the ?Date gets appended to the image. After I crop an image, I'm still seeing the original image in my browser because the url is still the same. Looking at theme developer module output, it looks like it is only being run through theme_imagecache(). Maybe imagecache is hijacking the theme call?
Comment | File | Size | Author |
---|---|---|---|
#33 | imagecache-689470-1-6x20rc1-D6.patch | 741 bytes | kndr |
#29 | imagecache-689470-1-D6.patch | 707 bytes | kndr |
#11 | imagecache-force-reload-image-on-edit-2.patch | 1.09 KB | gnindl |
#8 | imagecache-force-reload-image-on-edit.patch | 609 bytes | gnindl |
Comments
Comment #1
shraddha.sawant CreditAttribution: shraddha.sawant commentedHi,
I had similar problem. I referred http://www.thingy-ma-jig.co.uk/blog/14-11-2009/drupal-imagecache-perform.... It solved my problem.
I hope it helps!!!
Comment #2
frankcarey CreditAttribution: frankcarey commentedthanks @shraddha.sawant, but this an issue even for internal sites.
Perhaps this is more of an imagecache issue?
Comment #3
John Pitcairn CreditAttribution: John Pitcairn commentedSubscribe. I am having exactly this problem too.
I might have to resort to manually parsing the themed imagecache output and adding the timestamp myself. But would love to see this resolved.
See also: http://drupal.org/node/212622#comment-2993946
Comment #4
John Pitcairn CreditAttribution: John Pitcairn commentedOK, manually adding a timestamp works well enough, when my image display is done by calling theme('imagecache' ...). The output of that can be parsed for '.jpg' and a timestamp added, since I already have the imagefield details loaded.
But that doesn't help if the imagecache display is being automatically included in the $content variable by the content-type's "display fields" settings.
Comment #5
John Pitcairn CreditAttribution: John Pitcairn commentedComment #6
drewish CreditAttribution: drewish commentedCould you please confirm this is still a problem with the current -dev release?
Comment #7
John Pitcairn CreditAttribution: John Pitcairn commentedThe development site is currently undergoing some major changes, but I'll try the dev release when I re-enable Imagecache and let you know, thanks.
Comment #8
gnindl CreditAttribution: gnindl commentedI suggest to add the timestamp to the image URL by default. When you update an imagefield for example, the imagecache derivative is not updated immediately, as the browser doesn't reload the image.
Similar issues have been solved for imagefield, see http://drupal.org/node/709424.
In the dev version you just have to change the imagecache_create_url() method signature, from
to
Comment #9
drewish CreditAttribution: drewish commentedI'm pretty sure that's a bad idea. You're effectively telling every browser to never, ever cache the image but instead download it again and again.
Comment #10
John Pitcairn CreditAttribution: John Pitcairn commented(removed, sorry)
Comment #11
gnindl CreditAttribution: gnindl commentedOk, that's true, #8 is not a good idea.
Now I have a different, not ideal, approach which loads the timestamp from the "files" table and appends it to the URL.
In an ideal world you would have the file object as an parameter of the image_create_url() function avoiding to have to query the database unnecessarily once more.
Comment #12
YK85 CreditAttribution: YK85 commentedHello,
I use views to add a field, select an imagecache preset and show images on a page. I noticed the image URL on the views page is shown as below without a timestamp. Is it suppose to have a timestamp appended to the file name?
Comment #13
YK85 CreditAttribution: YK85 commentedAWESOME! I have been looking for this fix for a long long time!
I had to manually apply the patch.
Now the image url is showing as below and it updates properly after editing (I use imagefield crop module)
I hope this can get committed soon!
Comment #14
rburgundy CreditAttribution: rburgundy commentedgreat work! confirmed it fixed my issues as well
+1 for commit
Comment #15
YK85 CreditAttribution: YK85 commentedI updated to latest dev (2010-Jul-11) and the problem came back as I forgot to reapply this patch =/
Any chance to see this committed soon? Thanks!
Comment #16
robby.smith CreditAttribution: robby.smith commented#11 did the trick! RTBC all the way
Comment #17
YK85 CreditAttribution: YK85 commentedI really hope this can be added to the latest dev =)
Comment #18
Bilmar CreditAttribution: Bilmar commentedsubscribing
Comment #19
chuckbar77 CreditAttribution: chuckbar77 commentedTested and fixed the issue I was having. Many many thanks!
Comment #20
chuckbar77 CreditAttribution: chuckbar77 commentedHi there,
Please commit and review by maintainer.
Would appreciate very much!
Comment #21
chuckbar77 CreditAttribution: chuckbar77 commentedbumping priority to major - i hope this may get more attention
Comment #22
Bilmar CreditAttribution: Bilmar commentedgreat work - please commit to latest dev
Comment #23
chuckbar77 CreditAttribution: chuckbar77 commentedHappy New Year!
Thanks for a great 2010. Hope this can be added in 2011 =)
Comment #24
YK85 CreditAttribution: YK85 commentedIs there another method of doing this or is there a reason #11 hasn't been committed after 7 months?
Many thanks
Comment #25
YK85 CreditAttribution: YK85 commentedHad to patch the dev version again =(
Please kindly commit to the core module.
Thank you
Comment #26
bora-89 CreditAttribution: bora-89 commentedAwesome patch!
But it needs to be incorporate in the core...
Comment #27
drewish CreditAttribution: drewish commentedThe whole query per image kind of stinks form a performance standpoint. I suppose that makes a filestat() to find the date seem more reasonable. What about changing the format of $bypass_browser_cache so that if it's TRUE we keep the current behavior but if it's not a Boolean we just stick that bit into the query string?
Thoughts?
Comment #28
aether CreditAttribution: aether commentedI personally like the approach in #27. It provides the freedom to define the query string by multiple means. I could query the database, use filemtime(), or whatever as I see fit.
Comment #29
kndrI agree that #11 will have performance impact (I don't like it) but I like the idea of this solution. In my opinion we can use filemtime() function to achieve the same effect. This kind of functionality would be very usefull. For example, I am using the following stream in my application: imagefield => imagefield_crop => imagecache => colorbox. Unfortunatelly, browser cache doesn't refresh after image cropping. I suspect, there are some other situations, where imagecache is used and there is no quick, easy and elegant solution to avoid this kind of problem. Unix timestamp from filemtime() can solve this problem and images could be properly cached by browser. I am attaching a patch. What do you think?
Comment #30
gnindl CreditAttribution: gnindl commentedPatch in #29 sounds like an excellent solution. +1 for commit!
Comment #31
caspercash CreditAttribution: caspercash commentedUsed the #29 patch but this error keeps appearing
warning: filemtime() [function.filemtime]: stat failed for sites/default/files/image.jpg in sites\all\modules\imagecache\imagecache.module on line 345
Comment #32
fizk CreditAttribution: fizk commentedMarking as ImageCache 3.x Todo.
Comment #33
kndrHere is the #29 patch for imagecache 6.x-2.0.rc1
Comment #34
loparr CreditAttribution: loparr commentedIs this code working ok?
with this patch a number is appended after .jpg like .jpg?123 but the problem is that the number is allways the same after any changes was made to presets or after flushing cache.
However the sample image - country with baloon on imagecache setup pages is updating url as intended.
Where can be the problem? Maybe that all presets are pulled by views?
Comment #35
c4rl CreditAttribution: c4rl commentedThis seems good to me.
Comment #36
loparr CreditAttribution: loparr commentedCan anyone confirm that generating a number after imagename does not work? It generates a number but it stays the same even after flushing. Thank you.