Image resize threshold of 10 remote images has been reached. Please use fewer remote images.

Same error but it's only the new anti-flood filter, only refresh the page several times to generate image derivatives.

Plus: Remember to disable error messages to users in a production site: admin/settings/error-reporting :

• Development site: screen and log
• Production: only log

So I'm getting this message as an admin. What does it actually mean? What does it want me to attend to?

Do you mean we'd better not use remote image here?

This is happening on 7.x-1.14 as well.

Im having the same problem and i cant seem to hide it either. Im on Drupal 7.26.

If your users are using a proxy this is a big problem, so, you can increase the limit simply increasing the variable: image_resize_filter_threshold

variable_set('image_resize_filter_threshold', 1000);

Same error fo rme

Image resize threshold of 5 remote images has been reached. Please use fewer remote images.

Any fix for it?

Thanks!

Drupal 6.31

oriol_e9g on, thanks!

#7 seems to be doing the job ! Tahnks

I wasn't sure where to add the code from #7.
I added $conf['image_resize_filter_threshold'] = 1000; to the bottom of settings.php

It would be nice if this was a setting somewhere we could change through a GUI.

FYI: drush vset image_resize_filter_threshold 1000 will do the job, too.

This happened to me just now on a D7 site. Bumping it up helped my script, not sure if this can be prevented when using Batch API?

The OP posted about remote images, but many posters on the thread are talking about the slightly different warning for flood prevention:

Image resize threshold of 5 per minute reached. Some images have not been resized. Resave the content to resize remaining images.

The solution in #7 seems good. However I would interested to know what are the potential disadvantages of this change. The code was introduced in 7.x-1.14 as part of this commit http://cgit.drupalcode.org/image_resize_filter/commit/image_resize_filte.... I haven't been able to find any further explanation of the reasoning.

It's not obvious to me why the flood prevention would be needed. I am thinking about denial of service - but I can't see the scenario where a hostile user can generate unlimited resizing. The code we are looking at here runs as part of the filter process callback which is called from check_markup and similar functions. A user would need access to edit content to generate unlimited resizing.

On the other hand, there are legitimate scenarios where a "flood" occurs. The resized images may be missing after restore from backup or for a new server added to load-balancing. Many pages can be requested at once: when the search index is rebuilt from cron; if a new CDN enabled and requests all site content; or simply on a busy site. In all these cases, it seems like we do want to allow the 'flooding' because we want the new server to become operational as soon as possible, rather than waiting for hours or days.

Net result as far as I understand it: this flooding code can be harmful and I can't see how it helps. Please, please let me know anyone who can help me understand. In the meantime, I'm setting the threshold very high on all my servers...

OK, I have found the answer, see SA-CONTRIB-2014-017

In particular

This vulnerability is mitigated by the fact that an attacker must have a role that allows them to post content that utilizes the image resize filter.

In my case, I trust users on my site that can post content not to be attackers, so I think I am OK. If anyone else is reading this thread, they may want to read the SA before disabling the checking.

Sorry to those following for triggering multiple emails.

One final observation is that surely an attacker with a role that allows them to post content can cause DoS in any case by uploading more and more content until the server runs out of memory/disk/database capacity. The image resizing is therefore perhaps the least of your problems.

However the flood prevention can prevent legitimate image resizing in some cases as per my previous comments.

If I have made any mistakes and anyone would like to correct me (particularly those involved with the original SA), I would be very grateful.

Thanks, Skreenack; been seeing that on Romance Studies for some time now, finally got around to looking for a solution!

We are using the Stage File Proxy module in environments outside of Production. I think this message, Image resize threshold of 10 remote images has been reached. Please use fewer remote images., is related. At least in this case.

#12 worked great - thx!

This message should be converted into logger alert to be logged in the recent log messages instead of showing it to the end user because it's out of the end user control so it should be visible by the admin or the site editor only!

The following patch should do that for Drupal 8 version.

+1 to Omar's suggestion/patch in comment #20.

@Omar thanks for patch #20. However it no longer applies.
Please reroll.

Also, would be great to consider #2984338: Allow Users to Set External Image Limit which can provide a UI for changing this setting instead of drush.

@Razem I re-rolled the patch to work with the latest version and will postpone the UI setting a little bit.

#20 will work with 8.x-1.0-beta1, and #23 will work with 8.x-1.0.

+1 to Omar's suggestion
I found another related bug also: Call to a member function addMessage() on null in Drupal\image_resize_filter\Plugin\Filter\FilterImageResize->getImages() line 118
This happened because the "messenger" is not injected in FilterImageResize class
This patch will solve this issue also on the latest dev version

This looks great but I'm a bit worry that if we convert the message into a logger alert there won't be any visual message letting the user know that something is wrong and the images aren't being resized at all, it just won't work. right?

I'm mean there will be cases where the user assumes that all is working as expected and let it in that way for weeks/months especially when initially it was working and after some time at some point and for specific nodes it stopped working.

Maybe would be a better approach to improve the message, let the user what is happening and what can do to fix it and yup this needs to be logged as well.

I don't think that normal users (visitors) should know that there is a problem. We need to notify admins only, so I think an error log could solve the issue.

What about if we display the message only to users that can do something to fix the problem for instance users with the permission "Administer text formats and filters"?

I will try to work on this today.

Since #3100899: Drupal 9 Deprecated Code Report was fixed the patch at #25 didn't apply anymore, so here a rerolled version of the same patch.

Ok, I read the code to understand how this is working, and I changed my opinion.

Right now the threshold is 10 images in a window of 2 minutes, if any user uploads more images the message will appear with misleading information, I guess in the Drupal 7 version of the module the threshold is per request and not per time, that is why the message ask for re-save the content but in the Drupal 8 version of the module this is not the case, even if the content is re-saved the images won't be resized until 2 minutes has passed.

In the other hand, as Anas_maw said In the bit majority of the cases, the interest to resize the images is for the admins/webmasters not for regular users, there is no use to display the message to users because for them the images will look ok and the message is asking them to do something that does not fix anything.

I guess the best solution for this is:

Stop using the messenger and keep the logger as Omar suggests, AND allow the admins to set the threshold and window as Mohammed J. Razem suggested at #22.