Hi - we have tried using this plugin on a site that has 100 images and get the following error:

WD cloudinary_stream_wrapper: Failed to get sub-folders under folder [advertisement-images/2016/02fm12_3], [Rate Limit Exceeded. Limit of 500

It also seems to massively impact page response time.

Any ideas why?

CommentFileSizeAuthor
#2 cloudinary-rate_limit_exceeded_for_a_small_number_of_images-2668956-2.patch3.84 KBdanielmrichards

Comments

androidbloke created an issue. See original summary.

danielmrichards’s picture

danielmrichards commented
StatusFileSize
new cloudinary-rate_limit_exceeded_for_a_small_number_of_images-2668956-2.patch3.84 KB

I have run into the same issue as @androidbloke; albeit at a much larger scale. Our web platform has several thousand images and we were regularly hitting the Cloudinary rate limit even after we had requested it to be raised to 10,000!

The reason for this is that the loadResource function in CloudinaryStreamWrapper.inc makes a call to the Cloudinary API every single time it displays an image. This is not a problem if you cache the output of your pages via Varnish or some kind of load balancer or CDN. But for websites that do not do this for every page (e.g. eCommerce websites without auth cache) this is a real problem.

My proposed solution is to make use of the File Entity module. This keeps track of the original dimensions of your uploaded images which is really all the loadResource function is calling the admin API for.

File Entity is quite a large module so I do not think it should be a dependency of this module, instead I am using a module_exists check to make it an optional choice.

So basically install this patch and File Entity @androidbloke. You should see the API usage go way down for newly uploaded images.

danielmrichards’s picture

danielmrichards commented
Status: Active » Needs review
klokie’s picture

klokie commented
Status: Needs review » Needs work

Hi, Is this still an issue with 7.x-1.3? I noticed the patch doesn't apply anymore.

nbucknor’s picture

nbucknor commented

Hi, Is this still an issue with 7.x-1.3? I noticed the patch doesn't apply anymore.

@klokie @danielmrichards, This patch isn't really necessary if you use one of the cloudinary_storage submodules.

cloudinary_stream_wrapper_load_resource() calls cloudinary_stream_wrapper_resource_prepare()...
which invokes hook_cloudinary_stream_wrapper_resource_prepare()...
which is implemented by cloudinary_storage_cloudinary_stream_wrapper_resource_prepare()...
which will automatically pull a stored resource from storage instead of making an API call.

That being said, I'm not sure why \Cloudinary\Api::resource() is being used here instead of \Cloudinary\Uploader::explicit(). From what I understand, calls to explicit() do not count against your API limit while returning the same result as resource()

grask0’s picture

grask0 commented
Status: Needs work » Closed (outdated)

D7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.

If the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.

Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.