Hey all,
I know some people were working on a gif plugin. However, I suggest to add http://giphy.com support to the onebox plugin as long as we do not have a proper plugin (and we might want to keep it for later as well).
Giphy provides all (most?) gifs as well as mp4. Unfortunately, the mp4 url does not end on mp4, but on html5. So that is why it does not work automatically.
Instead of oneboxing Giphy, I’d almost be more interested in seeing installation-local support for looping short videos:
This is almost certainly a very low priority feature, but It’d still be nice to have. 
This old thread is related, but misses a key point of what I’d like to see. That being ideally these looping videos should have a user experience that is exactly identical to directly attaching a .gif, aside from automagically consuming less bandwidth (and/or being higher quality).
Showing video player controls and invoking “video” presentation semantics is… very 
.
In the meanwhile I suggest to embed giphy gifs. It cannot be so difficult to
write a plugin for onebox. The data is already there:
Have a look at the opengraph.
Best,
Robert
I prepared a giphy html5 video version, but it does not work due to the being stripped out autoplay at some point for any reason. Also, I do not know if autoplay would be a good idea performance wise in topics with many autoplay videos…
https://github.com/rriemann/onebox/tree/giphy_video
https://github.com/rriemann/onebox/commit/f3f45faa04b57501c0a89d92bd8923c367f81e59
It looks like the current giphy support in Discourse might be broken? On my site, this plays correctly for five minutes as long as it’s pointing to an external host, then when Discourse tries to mirror it in S3 locally after 5 minutes as normal with image uploads, it won’t animate anymore.
Nope, that is new functionality. Any external image larger than (x) will be blocked as a bandwidth hog (for mobile, etc) unless you explicitly allow it in your site settings.
You will see a placeholder and have to click through on it to see the giant 40 megabyte plus image, rather than having it hotlinked live.
Ah, OK! thanks for the quick response; that makes sense.
Would it be easier to not try to mirror images beyond a certain size threshold in that case?
“Bandwidth hog” doesn’t just mean for the forum. It’s mostly for the user’s benefit.
Could it be that this feature is broken? Let’s see (I’m pasting https://media.giphy.com/media/Lcn0yF1RcLANG/giphy.gif below):
Edit: okay, this is strange: discourse handles this gif in rather unpredictable ways. The first time I published this post, there was absolutely nothing in the rendered post. Then I added it to transparently mention the url I’m pasting and that produced a broken image placeholder the size of the actual image. The editor preview here on meta consistently shows a small broken image icon (not the size of the image).
On another site that I’m administering, the editor always shows the actual animated gif but the rendered post shows no trace of the image at all. Except when I rebuild the post-html, the url shows up as a link for a split second before it disappears again.
And finally, while I typed the above, the broken image placeholder in the post has disappeared from the rendered post. So at least after some time, the rendered posts look the same across sites, but still, something is wrong here.
Can you verify this has not regressed @vinothkannans?
I wonder if it’s part of Giphy’s effort to make it very difficult to hotlink gifs? the link https://media.giphy.com/media/Lcn0yF1RcLANG/giphy.gif isn’t an actual link to a gif (it used to be!), it’s a giphy page with an embedded webp.
This is now fixed as per below commit. @tophee now the large image placeholder is displaying in your post.
https://github.com/discourse/discourse/commit/c499872597e608bcc23de56fc853dcd8f5079a16
