Needs review
Project:
Cloudinary Integration
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Jul 2018 at 17:46 UTC
Updated:
3 Feb 2020 at 13:18 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
berdyshev commentedfixed patch paths
Comment #3
Phil Wolstenholme commentedEdit: I have misunderstood named transformations vs chained transformations so I am not sure my comments are valid anymore.
It might be unrelated, but having applied this patch I'm noticing I'm getting incorrect transformation URLs when multiple named Cloudinary transformations are being used together:With patch:https://res.cloudinary.com/…/image/upload/s--54KiOQT_--/t_q_auto/t_f_auto/t_w_auto/t_c_limit/v1/2020-02/gilly-uItNiF1vv4E-unsplash.jpg?itok=C-a6Cfyy
The above returns a 400 error.
I think the URL format should be:
https://res.cloudinary.com/…/image/upload/s--54KiOQT_--/q_auto,f_auto,w_auto,c_limit/v1/2020-02/gilly-uItNiF1vv4E-unsplash.jpg?itok=C-a6Cfyy
-----
I've done some XDebugging:
With this patch, a call toCloudinary::cloudinary_url($source, $options);is returning the incorrect URL https://res.cloudinary.com/dywlbz3eg/image/upload/s--54KiOQT_--/t_q_auto... – I suspect we are passing data to the Cloudinary SDK that it does not expect.Comment #4
Phil Wolstenholme commentedI think this data structure might not be what the Cloudinary SDK expects?
Comment #5
Phil Wolstenholme commentedChanging status back to needs review.