Handling of broken onebox images from malconfigured sites
A discussion about broken onebox images from misconfigured sites that block ‘hot’ linking of images. TallTrees suggests that Discourse could retrieve the image when cooking the post and store a thumbnail to serve later. However, Falco points out that Discourse already does this in the background, but only if the “download remote images to local” setting is enabled.
TallTrees discovers that this setting was disabled on their site and enables it, which should resolve the issue. Falco cautions against deviating from default settings without careful consideration of the repercussions. TallTrees notes that the setting change was likely made by a previous admin and is hopeful that it will also improve the persistence of images in Instagram oneboxes.
CodingHorror mentions that onebox now provides better feedback when it can’t onebox, explaining why it failed.
I see quite a lot of misconfigured sites that look to use various methods to block ‘hot’ linking of images, but return links to such images in the embedding data e.g.
Checking with http://debug.iframely.com/ I really think this isn’t a Discourse problem per se, but it does look poor.
One thought is that the onebox creation could retrieve the image when cooking the post and either store a thumbnail to serve later, or if it couldn’t be retrieved act as though there was no image specified.
Storing a copy of the image would be fairly robust and future-proof, and I think should fall under fair-use for copyright purposes (the original site isn’t going to be worse-off for the reuse of a 130x90 thumbnail which was retrieved from meta-data, though IANAL).
Failing that I tried making a component to catch the error event on images and then add a class to display:none them or their wrapper. I’ve not succeeded yet as I got bogged down in decorateCookedElement()… I’m not sure if I’m looking in the right place.
So, is it just me that seems to suffer broken images frequently in oneboxes - has anyone else got a workaround?
It’s obviously not at cook time, because you don’t put web requests on that critical path, but we queue it and download the onebox image in the background.
We wait editing grace period (default 300s) to download it if download remote images to local (default true).
It’s important to be careful and ponder the repercussion when changing the default settings. We ship with optimal choices out of the box, and deviating from those can have unintended consequences .
