decap-cms: [Cloudinary] Image URL in Editor preview broken with output_filename_only option
Describe the bug
When using the Cloudinary Media Library integration, I want to use the output_filename_only
option to take advantage of URL transformations. However, this option seems to break the rendering of the preview images.
To Reproduce
Switch Cloudinary image assets to output_filename_only
and observer the broken image links in the editor.
Expected behavior We would expect the editor preview components to build the preview URL for the image to append the the image filename.
Screenshots
Applicable Versions: Netlify CMS 2.3.0
CMS configuration https://gist.github.com/ksherman/cb5b319858b8ea06fbf638818f839d84.js
Additional context You all are awesome and I know this feature was juuuuust released š
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 10
- Comments: 19 (4 by maintainers)
Commits related to this issue
- Image URL in Editor preview broken with output_filename_only option #1934 — committed to hringleikur/netlify-cms by tom-intelesense 5 years ago
One additional point here, is i can organize images into folders in cloudinary at which point the output filename should be
<folder name>/<file name>
instead of justfilename
Subscribing to this. Especially with RWD images, itās a lot easier to use URLs in templates to do the heavy lifting.
output_filename_only: true
makes sense in that case but it breaks the preview and the user experience in the CMS.I understand a zero config solution would be ideal, but wouldnāt the most flexible option still be to add an
output_preview_path
?Currently using full Cloudinary URLs and a custom 11ty filter to get the filename and create the URLs I need, which means I am loading the full images in the CMS.
Currently there is still no solution for the option
output_filename_only: true
I would like to keep this open @erquhart
I encountered this issue also - the workaround I found was to set
output_filename_only: false
, and in the html templates, use a Hugo snippet to split the string and recover the assetās name, isolated from the full path.With this asset name string, I appended it to the Cloudinary transform URL string that was set to a variable.
{{ $.Scratch.Set "cloudinaryAssetName" (index (split .cloudinaryFullURL "/") (sub (len (split .cloudinaryFullURL "/")) 1)) }}
<img src='{{ $.Params.cloudinaryPathThumb }}{{ $.Scratch.Get "cloudinaryAssetName" }}'
here
{{ $.Params.cloudinaryPathThumb }}
= āhttps://res.cloudinary.com/myuserid/image/upload/w_200,c_scale/āand
{{ $.Scratch.Get "cloudinaryAssetName" }}
= āassetname.jpgāThis outputs the desired path:
<img src='https://res.cloudinary.com/myuserid/image/upload/w_200,c_scale/assetname.jpg'
ā¦and avoids the original problem with the Editor Preview being broken, as weāre using the full Cloudinary URL!
+1 - this is pretty much required for the
output_filename_only
option to be usable at all.For now Iāll be parsing the full URL and inserting my transformations that way, but it would be great if Netlify CMS was able to realize that Iām using an image hosting service capable of resizing and use thumbnails instead of full rez images in the admin interface.
Added a pull request that addresses the most basic case here, but it is still a problem when the markdown widget is used because the āpath onlyā version gets inserted into the markdown. Ideally, the markdown editor would also have a ābase_image_urlā option.
Widget preview components provide a default preview for an individual field. We would make the image widget provide the image as expected by default. If someone wants the actual field value, they can still access it in a custom preview template (or custom widget preview component), so everyone wins.
The challenge is doing this in a generic way so that the image widget makes no assumptions about your media library, hence the need to provide some sort of cooperative API between these two extension points.
Sent with GitHawk
Iāll be going through PRās soon, but I think the best way to handle this is probably by some cooperation between the media library and the image widget preview component. Still need to think through how that would work, but the logic for connecting the url value with the Cloudinary root url is simple, just a matter of where that should occur and whether itās possible without requiring configuration. I think it is.
Awesome work on the Cloudinary integration!
I think what is needed here, is that the CMS integrates the ācloudinary-reactā package from npm, gets the cloudname from the config.yml, and then displays the React component like this:
Or alternative, without React (Just get the correct url with the cloudinary-core module):
Iāll take a look and see if I can make a PR, but donāt expect too much š