Details
-
Type:
New Feature
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: 0.2.0
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
To avoid caching of old/expired images (in browser-cache and/or proxy cache) it would be helpful to tell SmartSprites to generate the names of the sprite-images using a specific pattern or even using the current timestamp. This will tell every browser to download a new/updated image when there was a change on any sprite.
I've done the same thing for the generated css-Files of SmartSprites. I'm using the ant task for our build process with the following properties:
<tstamp>
<format property="TODAY" pattern="yyyyMMddHHmmss" />
</tstamp>
<smartsprites rootdir="${root.dir.path}"
documentrootdir="${document.root.dir.path}"
outputdir="${output.dir.path}"
cssfilesuffix="${css.file.suffix}-${TODAY}"
csspropertyindent="${css.property.indent}"
loglevel="${log.level}"
spritepngdepth="${sprite.png.depth}"
spritepngie6="${sprite.png.ie6}" />
So everytime I generate the sprites and corresponding css files via ant the current timestamp will be added to the css file names. So there will be no caching issue on the user's browser.
I suggest an additional attribute like "spritefilesuffix" which will be appended to each of the defined sprite names on top of each original css file automatically. So I can append the timestamp to the image filenames as well.
An even better way would be that SmartSprites generates a hash which changes every time there is a true! change on the image file (and not on every task execution) itself. Maybe there is a way to identify each image composition unambiguously. We cannot use the file size as the identifier - this will not reflect a unique image composition. Maybe we can use the last modified timestamp of each file composing the individual sprite-image. But maybe this will become too complicated because we have to check for changes in the original css files as well (because the margin-* properties could have been changed as well).
Issue Links
| This issue is duplicated by: | ||||
| SMARTSPRITES-25 | Add MD5 hash in sprite image file names |
|
|
|
| SMARTSPRITES-41 | Sprite image MD5 hash or date should be part of file name rather than a request parameter |
|
|
|
Good point again! For the time being, in one project for which I've actually developed SmartSprites (http://demo.carrot2.org/demo-3.0/search), I'm doing the versioning independently of SmartSprites, but it does make sense to add the feature you mentioned. I think generating a hash should not be too much of a problem – I could simply generate the hash of the final sprite bitmap, and this would automatically take into account sprite margins, image changes etc (if you change margin, the sprite image will change, so should the hash).