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'];


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?

Members fund testing for the Drupal project. Drupal Association Learn more


shraddha.sawant’s picture

I had similar problem. I referred It solved my problem.
I hope it helps!!!

frankcarey’s picture

Project: ImageField » ImageCache
Version: 6.x-3.x-dev » 6.x-2.0-beta9

thanks @shraddha.sawant, but this an issue even for internal sites.

Perhaps this is more of an imagecache issue?

John Pitcairn’s picture

Subscribe. 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:

John Pitcairn’s picture

OK, 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.

John Pitcairn’s picture

Version: 6.x-2.0-beta9 » 6.x-2.0-beta10
drewish’s picture

Status: Active » Postponed (maintainer needs more info)

Could you please confirm this is still a problem with the current -dev release?

John Pitcairn’s picture

The 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.

gnindl’s picture

Status: Postponed (maintainer needs more info) » Needs review
609 bytes

I 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

In the dev version you just have to change the imagecache_create_url() method signature, from

imagecache_create_url($presetname, $filepath, $bypass_browser_cache = FALSE)


imagecache_create_url($presetname, $filepath, $bypass_browser_cache = TRUE)
drewish’s picture

I'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.

John Pitcairn’s picture

(removed, sorry)

gnindl’s picture

Ok, 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.

YK85’s picture


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?
YK85’s picture

Status: Needs review » Reviewed & tested by the community

AWESOME! 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!

rburgundy’s picture

great work! confirmed it fixed my issues as well
+1 for commit

YK85’s picture

I 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!

robby.smith’s picture

#11 did the trick! RTBC all the way

YK85’s picture

I really hope this can be added to the latest dev =)

Bilmar’s picture


chuckbar77’s picture

Tested and fixed the issue I was having. Many many thanks!

chuckbar77’s picture

Hi there,

Please commit and review by maintainer.
Would appreciate very much!

chuckbar77’s picture

Priority: Normal » Major

bumping priority to major - i hope this may get more attention

Bilmar’s picture

great work - please commit to latest dev

chuckbar77’s picture

Happy New Year!

Thanks for a great 2010. Hope this can be added in 2011 =)

YK85’s picture

Is there another method of doing this or is there a reason #11 hasn't been committed after 7 months?
Many thanks

YK85’s picture

Had to patch the dev version again =(
Please kindly commit to the core module.
Thank you

bora-89’s picture

Awesome patch!
But it needs to be incorporate in the core...

drewish’s picture

Status: Reviewed & tested by the community » Needs work

The 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?

  $args = array('absolute' => TRUE, 'query' => $query);
  if ($bypass_browser_cache) {
    if ($bypass_browser_cache === TRUE) {
      $args['query'] = array(time());
    else {
      $args['query'] = $bypass_browser_cache


aether’s picture

I 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.

kndr’s picture

Version: 6.x-2.0-beta10 » 6.x-2.0-beta12
Status: Needs work » Needs review
707 bytes

I 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?

gnindl’s picture

Patch in #29 sounds like an excellent solution. +1 for commit!

caspercash’s picture

Used 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

fizk’s picture

Issue tags: +ImageCache 3

Marking as ImageCache 3.x Todo.

kndr’s picture

Version: 6.x-2.0-beta12 » 6.x-2.0-rc1
741 bytes

Here is the #29 patch for imagecache 6.x-2.0.rc1

loparr’s picture

Is 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?

c4rl’s picture

Status: Needs review » Reviewed & tested by the community

This seems good to me.

loparr’s picture

Can 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.