If you need to update an existing transformation, the simplest solution is to either create a new transformation under a new name, or to use dynamic transformations rather than named transformations.
If you still want to keep the current transformation's name, then:
- If you have less than 1000 images associated with this transformation, you can use our management console (or admin API) to delete the current transformation, including associated derived images, and create a new one under the same name.
- If you have more than 1000 images associated with this transformation, you can use our admin API to update the transformation, but the new settings will only be applied to newly generated images.
Here are two examples:
Cloudinary::Api.update_transformation("my_named_transformation", :unsafe_update=>{"crop"=>"scale", "width"=>103})
Cloudinary::Api.update_transformation("my_named_transformation", :unsafe_update=>[ {"crop"=>"scale", "width"=>103}, {:overlay => "badge", :gravity => :north} ])
The :unsafe_update parameter updates a named transformation parameters without regenerating existing images
Note that if you choose to keep the same transformation's name, only newly transformed images will be using the new transformation.
Comments
8 comments
Could we get examples in other languages?
this doesn't seem to work:
cloudinary.api.update_transformation('name_transformation', unsafe_update={'format':'jpg'})
Here are some code references in the various client libraries:
Node.js:
https://github.com/cloudinary/cloudinary_npm/blob/fb2448e5b1bbce476d2646c42ff906aeb08a25d8/test/api.coffee#L266
Python:
https://github.com/cloudinary/pycloudinary/blob/fefb6f8a6696e0fe59670f49ad8801954bb88fc0/tests/api_test.py#L206
PHP:
https://github.com/cloudinary/cloudinary_php/blob/135eb8465cd6c37a07e6f5314ad4b125d1062840/tests/ApiTest.php#L284
.NET:
https://github.com/cloudinary/CloudinaryDotNet/blob/071a91e5f1f0fc80cdddee5b4072c8bac030e219/Cloudinary.Test/CloudinaryTest.cs#L1341
Java:
https://github.com/cloudinary/cloudinary_java/blob/87df64e10cb70a520fc0407aa97a22db8031a0ce/cloudinary-core/src/test/java/com/cloudinary/test/ApiTest.java#L328
Hi guys - clearly this demonstrates room for improvement!
To be honest, I was always under the impression, I could save a named transformation, use the named transformation in the URL for images used for instance on a Android APP, then if required, I could just edit it in the Cloudinary Management Console > Media Transformations to make changes, modifications or updates, and see those changes come through the next time the image is requested.
This is a bit of a repeat of above... But for example, we create a named transformation using 100% quality and use it in the APP. After launching the APP we decide images for the APP need to be displayed at 50% quality instead. Instead of having to dev/update the APP and release an update, notify customers, etc etc, how wonderful would it be to just be able to edit the named transformation settings (which are there to be used) in the Cloudinary Management Console > Media Transformations, and see the changes come through live?!
Having the "Invalidate - True" option in the Named Transformation settings, would probably help no?
Hi Marcos,
Thank you very much for providing this feedback!
The current limit of 1000 images when updating a named transformation is to:
Please let us know if you have any additional questions.
Regards,
Millie
Hi Mille - but what if the new transformations are necessary, such as a adding a new watermark to all images? If we created a new transformation to cover this, we would end up affecting the quote anyway, in addition having to edit/dev/release the APP. Regarding the account quota, well that really should only be an issue if it's not clear to the user, and if they do not have enough credits (in our case we are are conscious would have enough), and this would also be the case when making the derived images resources available immediately, where we would obviously expect an initial slight delay loading new images the first time.
Nevertheless, I still think having the option to purge all previous transformations for an edited named transformation, would cover the points above.
@Marcos
I definitely agree, it's something that can be improved.
In the meantime, if you do update the named transformation, I can gather a list of assets that use that named transformations and invalidate those assets specifically. If you want, you can open a ticket internally with us and we can discuss it further.
Great - I will keep that in mind when we do require any changes to named transformations.
Looking forward to seeing this improved functionality for the user.
Please sign in to leave a comment.