When you overwrite an existing asset with a new file that uses the same public_id, the existing asset will be updated with the new file and new requests for that resource will receive the new asset right away.
However, if the asset was already in use in your application or website, you may still see the previous version of the asset instead of the newly updated asset.
The possible reasons for this behavior are:
- A CDN-cached version of the asset is being served.
- A browser-cached version of the asset is being served.
- Another 3rd-party cache tool has stored the previous version and is serving it.
CDN invalidation
When overwriting an asset using the Upload API, you will need to set the invalidate parameter to true e.g. in NodeJS:
cloudinary.uploader.upload(file, { invalidate:"true"},
function(error,result) {
console.log(result, error)
});
This will ensure an invalidation request is sent to our CDNs to clear any cache for the overwritten asset. If you are overwriting assets via the Cloudinary Console, this parameter is sent automatically.
By default, all possible delivery URLs for an asset will be invalidated, but if you have an older account using non-standard options, you may need to contact us to change the invalidation behavior for your account.
For more information about CDN invalidations, please see the upload API documentation
https://cloudinary.com/documentation/invalidate_cached_media_assets_on_the_cdn
Bypassing browser and other caches
Alternatively, or if you need to bypass users' browser caches as well as our CDN caches, you can include the optional version component as part of your asset delivery URLs.
The version number of an asset is included in theversion property when you receive the asset's details using our Upload API and Admin API responses. The url or secure_url parameters of our APIs also include an asset's current version, as do the URLs retrieved through our Cloudinary Console.
If you keep your database up to date with the version number for each asset and use it in the URLs that your application creates, you'll always receive the newest version of the asset, even if the user or a third party has cached it.
Comments
33 comments
Because we don't want to have to change the image URL in the HTML code on our site every time we update an image, we are not using the version in the URL. As such, does this then mean that if we replace an image through the Media Library it will take up to an hour to update on our site? Is there no way to manually clear cache or at least reduce that wait time to a few minutes?
Hi Jerry,
Usually this procedure shouldn't take more than a few minutes in order to be reflected to the majority of your users. However, since Akamai operates hundreds of thousands of servers around the world, our official commitment is for 1 hour invalidation.
If you're experiencing specific high latency, don't hesitate to contact us with details via a support ticket.
Hello,
What about tags and custom metadata? Are they getting overridden when uploading a new image with the same name?
Thanks.
Hi Nimrod,
Yes, this information is being overridden.
Thank you Nadav,
Is there any way to keep the information but update the image?
At the moment you will have to provide the tags & metadata within the upload request payload. I added a feature request on your behalf to support keeping the existing resource information. We'll make sure to update here once it becomes supported.
When I provide the public_id for linked images, the media library panel doesn't seem to be able to replace it. It creates a new image with the upload icon, and that image actually never appears. In short, the system doesn't seem to be prepared for this case, and the web panel has the bug of not properly indicating as such.
Please correct me if I'm wrong. I'd love to be able to replace linked images with manually uploaded ones.
Hi James,
Uploaded and Fetched resources do not collide and therefore cannot override one each-other. Furthermore, "fetched" resources cannot be set a name (it's automatically named after the URL from which it was fetched) and "uploaded" cannot be named with sequential slashes (e.g. "http://")
If you wish some further advising regarding your use-case, please feel free to open a support ticket and share some more information on your requirements.
i found the solution: auto-upload, which is virtually the same thing as fetched, excepted better. My suggestion is you guys remove the fetched solution--it's redundant and not as good and as a result complicates things for the user.
I also think you guys should lead more with this feature, i.e. in your marketing materials. I figured out you guys were the best in town for this sorta thing (compared to myriad competitors like cloudimage.io), but your homepage and main marketing pages barely made it clear that one of your features was the same thing that many companies like cloudimage.io do as their main offering. I feel like that's the most enticing way to get images into your platform these days. Just my 2 cents.
Hi James,
Your 2 cents are very much appreciated, thank you for the feedback!
Here's the relevant documentation and some comparison made between the two different features: http://cloudinary.com/documentation/fetch_remote_images
Feel free to contact us for further advising if necessary :)
My experience is that I am getting the same version number over and over again when uploading images with the same public_id as with code below:
let params = CLDUploadRequestParams(params: ["public_id":myID as AnyObject])
cloudinary.createUploader().upload(data: data, uploadPreset: "xxxx", params: params, completionHandler: {}
This is in Swift on iOS; might you shed light on the cause?
Thanks,
Marcos
Hi Marcos,
Make sure to use signed-upload protocol as the unsigned one doesn't allow overwriting existing images (for security reasons).
See: https://support.cloudinary.com/hc/en-us/articles/208335975-How-safe-secure-is-it-to-use-unsigned-upload-from-web-browsers-or-mobile-clients-
Using the Drag & Drop widget in the Cloudinary Media Library, how can I upload a new version of an image?
e.g., I already have a file in Media Library, "sample.jpg"
I want to replace that file with a newer version - so that only the version number (this part of the URL, /v9472981241) will change.
But, when I drag & drop the new file (named that same as the already uploaded file, sample.jpg), the file gets uploaded and I end up with a file name like, "sample_vpbqfw.jpg"
Is there a setting or something else that will allow me to be prompted when a 'duplicate' name exists, or that allows me to automatically update files is duplicate names exist?
Thank you in advance for the assistance.
Hi Robert,
You can set the public_id of a drag&dropped image by clicking the "More upload options..." button and setting the public_id to the image you wish to change.
Also, you can disable the random suffix characters when uploading - go to your account's Settings page and under Upload tab, choose Yes for "Use file name in Media Library"
Hello
I'm trying to update already existing image but unsuccessfully.
So, I set public_id, enabled versioning in settings but when I try to update existing image - nothing happens.
The image is still the same, the tags are still the same too.
There are two part of my code (I work with Angular, but the common logic is similar):
1) Init and calling uploader options:
let uploaderOptions: FileUploaderOptions = {
url: `//api.cloudinary.com/v1_1/` + ConfigurationConstants.CLOUDINARY_NAME + `/upload`,
autoUpload: false,
isHTML5: true,
removeAfterUpload: true,
additionalParameter: { crop: "fill", width: 120, height: 80 },
headers: [{
name: 'X-Requested-With',
value: 'XMLHttpRequest'
}]
}
this.setUploadingOptions(uploaderOptions);
2) Part of setting options:
setUploadingOptions(options: FileUploaderOptions): void {
this.uploader = new FileUploader(options);
this.uploader.onBuildItemForm = (fileItem: any, form: FormData): any => {
form.append('upload_preset', ConfigurationConstants.CLOUDINARY_IR_PRESET);
let tags = 'badge, ' + this.badgeForm.get('name').value;
form.append('tags', tags);
form.append('file', fileItem);
form.append('public_id', 'wxcpebbq7hwlzoozukgf'); // just to test
fileItem.withCredentials = false;
return { fileItem, form };
};
...
}
What I am doing wrong?
Thanks!
The #image_versions does not appear to scroll to anything.
#asset_versions ??
In this explanation is just says we can use the version component, with no description how. I turned it on, in my preset settings, with no effect.
Invalidate versioned URLs: enabled
preset-> overwrite: on
preset-> invalidate: on
I am using signed uploads, the new file appears on the cloudinary dashboard but the url remains the same.
Help would be good ?
Hi,
Thank you for pointing out the link. I have updated it so that it points to the right part of the documentation now.
Regarding using the version component, this isn't something that needs to be enabled as it comes automatically for all accounts. If you're uploading via the Media Library you will see that the version component is already included in the URL found when clicking on the image once it's successfully uploaded. And if you're uploading via the API you will see the version number is included in the URL parameter.
If you want to include version numbers in your URLs, I would recommend disabling the Invalidate versioned URLs setting as updating the URL with the newest version number when it's replaced will show the newest asset.
I hope this helps!
I'm using npm "cloudinary-react" on react.
Are you the owner of this package.
My uploads are showing the versions as you explained. but my client doesn't. I presume it some setting on this component?
Heres example of my images on client
http://res.cloudinary.com/thearsenalreview/image/upload/c_fill,dpr_2.0/v1/users/avatars/auth0%7C598a1da62171484ba580f807.png
Daniel
Hi Daniel,
If you create the URL with react we are not adding the version (we don't know the version).
For example:
Will generate a URL without version.
If you are using react only and update the image(with the same name). we would recommend contact us and we will update your account to invalidate only un-versioned URL.
Hope that helps,
Will this allow a user to change their profile image and instantly see it change?
Daniel
Hi Daniel,
How do you update the image when the user updates his profile image?
Hiya
I overwrite the same cloudinary publicId.
:|
You can add `invalidate:true` on upload and it will invalidate the new version. For example in NodeJS:
cloudinary.v2.uploader.upload(".../../myNewImage.jpg",{ public_id: "sample",invalidate:true },function(error, result) {console.log(result, error) });
Hi
I am using React (Widget). This example shared above is not useful fo me. I'm left with guesswork.
Invalidate is true on my preset?
So I am assuming I need to add this param to my upload on the client.
When should I add it, when should I not add it. ?
Anyways, I did add the invalidate (true) param with no effect.
Do we need to change setting on cloudinary?
Daniel
Hi Daniel,
May I ask you to please create a support request with an example URL that's being accessed but still showing the old image?
An invalidation request should be sent if the upload widget is used to overwrite the old version fo the file, but it's possible the URL format you're using doesn't match the URL format we send to the CDN for invalidation - we can verify that with a specific example and update your account configuration to match
Thanks,
Stephen
Hi Stephen Doyle
I am using the React Cloudinary Package to access the image <Image/> component. When I use this, it does not include the version number.
I feel others will have the same issue about this exact same topic, thus why to move it to a private ticket would not help others. Let me know if its still necessary move to a private ticket.
When I overwrite the image, it works. When I access the image using the <Image /> component I cannot include the version in the URL.
I cannot find any documentation on the <Image/> component such as possible parameters, or any that show this option
Please advise
Daniel
Hi Daniel,
By far the most likely reason you'll still see an old image is if invalidation wasn't requested when the old image was overwritten, or if the URL format we send to the CDN doesn't match the URL you're using to access the image. There are three possible URL formats we can invalidate, outlined here: https://support.cloudinary.com/hc/en-us/articles/360001208732-What-URL-conventions-are-invalidated
If you can provide an example image URL I can check which of those cases may have happened in your case; it's possible we need to adjust your account configuration from our side to make sure the URL format being invalidated matches what you're using on your site / in your app.
For example, most of our SDKs output option '1' on that link, which is also the default we invalidate, but if you're using React exclusively, because the Image component uses option '2', we'll need to adjust that for you
Thanks,
Stephen
Hi Daniel,
I just want to add to Stephen's above message. In React the parameters in <Image parameters /> and <Video parameters /> tag can include the version component. e.g.
<Image cloudName="demo" publicId="sample" width="300" crop="scale" version="1531412312"/>
Cheers,
Daniel
Hi
Yes, thanks, guys. The version param hit the spot.
Curious question, as it could have saved me a month of back and forth. Where is this in the documentation for that NPM Package. (I'm aware it should be obvious, but there's only a certain amount guesswork one can do before they get fed up of it, I did read everything, im sure, before I started posting)
Daniel
Hi Daniel,
The documentation for the React SDK doesn't cover the invalidation/versioning behavior in detail, but there are some knowledge base articles and it's mentioned in the main documentation too: https://cloudinary.com/documentation/advanced_url_delivery_options#asset_versions
Apologies for the delay in replying too; some of your comments here weren't sent to our support system correctly and so I didn't receive a notification that you'd replied; we've subsequently fixed that issue.
Regards,
Stephen
Please sign in to leave a comment.