Users are discussing an issue with the “blocked onebox domains” setting in Discourse. IanKelling reported that adding youtube.com to the blocked domains list did not prevent a onebox preview from appearing when posting a YouTube link. RGJ was unable to reproduce the issue, but suggested blocking youtu.be as well.
IanKelling discovered that setting max_oneboxes_per_post to 0 can globally disable oneboxes, resolving part of the issue. Further investigation by IanKelling revealed that the problem only occurs for domains that have already had a link preview generated. RGJ found that the cache is checked before the blocklist, which may be the cause of the issue.
nathank also encountered the problem and suggested that the cache and blocklist checks should be switched around to resolve the issue.
I put youtube.com in the “blocked onebox domains” setting. Then made a post with a youtube link. A onebox showed up. The expected behavior is no onebox preview. That should be reproducible.
Also there is no one way to disable onboxes globally that I can see. This is really annoying. One obvious way to allow this would be for “blocked onebox domains” to support *. If the main bug gets fixed, I suggest doing that along with it.
I am unable to reproduce this. Is the link in the form of https://www.youtube.com/watch?v=XXXX ? You might want to block youtu.be as well.
Just set max_oneboxes_per_post to 0.
Thank you. This works. I should have noticed this.
Yes, it is in that form.
Ok. I’ve done a bit more experimenting, and the issue only shows up for domains which have already had a link preview generated. So, if you create a new post, paste in a link to domain X, which generates a link preview box, (don’t even complete the post) then block the domain, then create a new post, paste in the same link, the link preview is generated despite it being blocked.
Additional info: version I tested on: Discourse 2.9.0.beta7 - GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. · GitHub version 5894e7d30f2c597b9750f6b6a55d81f9d101c037
Yep, seems like the cache is checked before the blocklist is checked: discourse/lib/final_destination.rb at main · discourse/discourse · GitHub
I’ve just encountered this problem too and it is quite an annoying bug.
Doesn’t this mean that those should be switched around?