Display Animated Gifs with the Download Remote Image To Local Enabled

Feature
1

We have our current site setting for ‘max image size kb’ set to 3072 (the default). This seems to work well as we don’t need to host enormous images.

We also have some rumbustious members that like to post links to animated gifs, i.e.

https://media.giphy.com/media/wh4f9iW5vCjgQ/giphy.gif

They want the gif to display in the posts, for maximum comedic effect (debatable…).

What happens is that the ‘download remote images to local’ is set to true (because we want that for image rot), and the system then comes along and tries to pull the .gif locally but then hides it as too big, using the ‘max image size kb’ as the threshold.

What people see for the above gif is:

image

Our members then want the 3072 KB lifted, even though that limit isn’t really about ‘download_remote’ or displaying gifs.

So what is happening is that the site setting for how large should images be that we would accept to be uploaded is also be used as the threshold of what is acceptable to view in a post. Ideally that would be two settings, as one is about storage costs and the other is about how nice should the bandwidth requirement be for people viewing the forum.

There may also be another solution for this, which I’m keen to explore, in that if ‘download remote images to local’ fails then could it just leave the link as an inline image regardless? It seems like it tried, found it too large (based on the upload setting) and then hides it with the click-through. Could we have a setting to alter that behavior instead?

Also, should we (or could we) start using the ‘disable image download domains’ as the place to collect up common animated gif sites and then start using that instead to get what we want?

Thanks for any ideas/help.

PS I do not condone animated gifs, I don’t want to talk about their value in our world, just how best to configure Discourse to allow them. :slight_smile:

1 Like
2

It might be easier to educate them about the many services that auto-convert giant GIFs to MP4 videos which are 1/10th the size. This was rare a few years ago, but much more common today.

And the MP4 videos can be linked and viewed perfectly!

1 Like
3

Yes, a lot of the GIF sites do just take the URL that’s shared and then wrap it in a container, which depending on the browser support will often just show a .webp MP4 video instead.

Unfortunately the ‘remote image’ sniffer (which I’m assuming is used to determine the image size from the Discourse end) gets routed to the underlying .GIF that’s often huge but works on anything.

So we’re in the situation where people are pasting things like:

…that then works fine, but then the ‘remote downloader’ comes along after 10 minutes and breaks it, because it goes to see what sort of filesize it is to download it locally and the GIF services then doesn’t recognize it as a valid agent, so gives back the enormous GIF size instead.

The fact that the ‘file upload max size’ setting is semantically overloaded in an unhelpful way to also mean ‘image that can be viewed inline max size’ is how I worded the feature ‘ask’, but the underlying need is really to be able to:

(1) Let our users grab common animated gif links from services like giphy.com
(2) They don’t get downloaded locally, but still work inline. If webp gets served up, even better.

Hmm, does it sound more like there could be a need for a Onebox that deals with these sort of gifs? It feels a ‘chase the service before it goes bust’ though, in that they might all have some odd rules on how to digest/wrap the onebox?

4

If you define “breaks” as “makes it accessible through a single click or single tap”, I suppose :wink:

I get your underlying point, but I think I’d need to hear this from some other places first, because the status quo seems pretty OK so far.

4 Likes
5

Understood, that’s reasonable. I’m not sure how common what we do is or not.

One thing I did notice, and that might help us, is that here on meta.discourse.org the gif in my example above seems to have stayed working. What do you have the max_image_upload_size and download_remote_images_to_local set to? It looks like the remote didn’t kick in here, which kept the link displaying the .webp version.

EDIT: Actually, it looks like the gif is only 670,285 bytes big, so under default size, so that probably explains it as it was grabbed remotely just fine.

2 Likes
6

I remember there is a setting to disable downloading images from certain sites?

Do you have to download the gif locally? Can you keep.it linked to the original source?

2 Likes
7

I think we tried that and I need to narrow down why that doesn’t work. I think in the case where a domain is blacklisted to remote download from then the link won’t appear in-line anymore, as in, it will give the text link but not show the embedded animated webp or gif in-place in the post.

I’ll do some experiments this morning and report back, as perhaps a tweak in that behavior might help (or it just works). Thanks!

EDIT: We added giphy.com, reactiongifs.com, tenor.com and gfycat.com to the disabled_image_download_domains setting and it seems to be working better so far for new posts. It doesn’t seem to work for rebaking posts, but that’s not such a big deal (and I think the reason we originally thought this might not work). Thanks @schungx!

3 Likes
8

Hmm, is that a bug @techapj? Why would it disable the image download on first post but not rebakes?

1 Like
9

Are you seeing this issue for rebaking posts created before the setting disabled_image_download_domains was modified or after?

3 Likes
10

I’ll check.

Steps to reproduce:

  1. Our settings are for a max 3 mb upload file and these remote image values:

image
image745×511 19.1 KB

  1. I remove tenor.com from our ‘disable image download domains’ exclusions list and save.

  2. I upload something from tenor.com smaller than 3 mb (in the underlying .gif that gets served, even though the services tend to browser sniff and deliver a

    Star Trek Impact GIF - Tenor GIF Keyboard - Bring Personality To Your Conversations | Say more with Tenor

  1. I upload something larger than 3 mb from tenor.com to see if when the remote image download comes around it does something or not. This gif compresses terribly, so is about 6 mb.

    Long Hair GIF - Tenor GIF Keyboard - Bring Personality To Your Conversations | Say more with Tenor

https://media1.tenor.com/images/c270efedc6b25c1dcdc848d6921b10bd/tenor.gif?itemid=9227004(image larger than 4 MB)

This results in:

  • As expected in step (3) is being copied locally ok (because tenor.com is not in the exclusion list now).

  • The step (4) post only had the image URL in it and is now completely blank, i.e. no ‘click here to see’ message. Is that a new bug, as previously I have seen ‘this image is larger than 3078 kb, please click to see’?

  1. I then place tenor.com back on the ‘disable image download domains’ in /admin and save.

  2. I go to the post in step (4), use the admin ‘wrench’ icon for the ‘post admin actions’ and choose ‘Rebuild HTML’.

This still results in the post in step (4) being blank, despite it being new and not past the 30 days old.

So from the steps above I think we are seeing it after.

11

Step (4) looks like it went blank here on meta.discourse.org as well, which is good as it’s recreatable. Before the remote downloader came around, the gif was showing in-place under the URL shown in step 4.

12

I meant to keep tenor.com in disable image download domains and then create a new post and rebake it.

Basically I was trying to debug the issue that Jeff mentioned here:

Testing locally, after adding “tenor.com” in disable image download domains creating and rebaking the post seems same. i.e. the gif remains intact without any placeholder text.

I think if we create a post without adding “tenor.com” in disable image download domains then it adds a “image too large” placeholder text when it goes through images, and then rebaking the post (with “tenor.com” in disable image download domains) doesn’t fix it because it ignores the image links with “tenor.com” in it altogether hence the placeholder text remains there.

Fixing the issue of adding placeholder for large images (that can’t be downloaded) needs more thought IMO as we need to consider all the cases and also understand why we added the placeholder in first place.

3 Likes
13

It did do that for us for a while, but on v2.1.0.beta4 +3 (and here on meta, looking at my post above) it seems like it doesn’t add the placeholder text anymore? My step (4) above just has the URL text that I put in for reference and then followed by a blank line - I’m pretty sure before for files over the upload limit it used to put a click through message…

I agree, and am not sure of what would work to be the ideal solution. For us I will say that the primary feature ‘ask’ was about how to make large animated gifs work, and we’re happy with the solution to use ‘disable image download domains’ as designed. The rebake isn’t a big issue for us, in that we can explain to our users that it works a certain way from now on, and we don’t have to go back and fix old posts desperately.

The placeholder being blank is probably the only issue that is worth a look though, as it was handy as an explanation to the user what had happened (it was too big, plus was not our ‘whitelist’ of good gif sites, so to speak).

Thanks for taking a look.

2 Likes