Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
When saving a new Cloudinary media entity using the provided media source in the cloudinary_media_library_widget module, the filesize attribute is not populated. This is especially a problem when using the CloudinaryRaw field type for using files and documents stored in Cloudinary.
Steps to reproduce
* Enable the cloudinary_media_library_widget module
* Create a new media type using Cloudinary as source and CloudinaryRaw / document as source type
* Create a media entity of this type
* Result: the filesize is not displayed when the media entity is rendered
Proposed resolution
When generating a file entity set the filesize property as was done in the past with the cloudinary media type plugins.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | cloudinary-3455065-5.patch | 1.29 KB | klaasvw |
| #3 | cloudinary-3455065-2.patch | 1.47 KB | klaasvw |
Issue fork cloudinary-3455065
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
klaasvw commentedThe following change will fetch the asset meta data and use the bytes property from cloudinary as the filesize property.
There's also an opportunity to reduce API hits and improve performance by caching the various
CloudinaryAssetHelpercalls. For example, when callingCloudinaryAssetHelper::loadAssetByPublicIdmultiple times Drupal is hitting the Cloudinary admin API more than is needed. Could be optimized by storing the assets in memory using a map in the CloudinaryAssetHelper service instance. I didn't implement this for now because it's not required for this change, but might be worth creating a new issue for this.Comment #4
klaasvw commentedComment #5
klaasvw commentedUpdated patch that checks if the assets exists (see #3479575: Handle deleted assets)