Dang, I’ll re-add this plugin next rebuild and hopefully it was just some temporary weirdness. Thanks again and sorry for the goose chase!
2 Likes
No worries, it’s always good to take a look at this plugin once in a while.
And on that note I’ve upgraded the structure of the plugin and added a minor tweak to the overrides to take account of a one-liner change in core (but was working prior to this in any case):
Core change: discourse/lib/oneboxer.rb at main · discourse/discourse (github.com)
New commit to plugin: IMPROVE: plugin structure, minor tweak to keep up with core · merefield/discourse-onebox-assistant@4c1d9bd (github.com)
3 Likes
Update to keep up with Discourse resolving a breaking change:
Breaking change: DEV: Don’t patch Sanitize::Config · discourse/discourse@46176b7 · GitHub
2 Likes
I’m trying to get this site to Onebox:
However, I get a code of 403 when using the standard Discourse oneboxing:
I confirmed that it will deliver a onebox on embed.rocks/try, and it does:
Therefore, I’ve setup this plugin and configured it as in the OP with an Embed.rocks account. It works fine on other sites, but for hinz.org.nz I get no onebox and this in the console:
I’ve trawled this topic but can’t find anything that helps. Any suggestions?
1 Like
That’s not a Onebox. Onebox is specific to Discourse so this doesn’t prove out enough. Embed.rocks is using all kinds of special cases and workarounds that are not a mirror of what Discourse is doing. We don’t use it to generate cards, so this is irrelevant for us, and it means you can’t use this as a safe test. We only use embed.rocks to return the original page source.
Have you checked the link on the FacebookMeta dev link opengraph checker tool? Any warnings?
2 Likes
Inspired by your post, I did spend some of my Sunday refactoring the plugin as it appears the Onebox gem has migrated into Core.
I don’t believe this was your issue, though as my overrides were working I believe, but now they are more thorough.
If you could please update and test this (version 3.0) I’d be grateful:
3 Likes
Hi!
I’ve enabled the plugin, but I can’t have Facebook oneboxes working. Is that expected? Did I misconfigure the plugin?
edit: a curl returns the famous “Log in or sign up to view”, and no box is created.
So, embed.rocks uses IPs that don’t have a reputation high enough for Facebook? 
1 Like
Is there a facebook embed format with a facebook api key?
1 Like
Uuuuh…
We can embed some Facebook posts for sure (only from public user profiles, not groups)… There’s also an API key used to embed Instagram posts…
But I’m not aware of something else. But there is something to be found in the developer dashboard, that’s quite a maze
1 Like
Are you sure that link is to a publicly exposed Facebook post?
1 Like
Just to close this question I completely forgot about: yes, the post was public.
Facebook previews worked 2 years ago, then they didn’t probably because of an “untrusted ip”, configuring their dashboard and maintaining the features is a pain and I gave up bothering with Facebook features on my forum in the end. 
2 Likes
Hi @merefield, some potentially useful feedback here.
tl;dr I had to reboot (restart Discourse) to get the plugin to use embed.rocks.
I installed the plugin on a staging box for a site I’m upgrading. I entered my API key from embed.rocks. I enabled the plugin and checked the “always use proxy” setting on, but Oneboxes didn’t get processed.
The sidekiq job seemed to fail quietly and then a new scheduled job would appear - presumably the retry?
There was nothing in the sidekiq queues jamming up Oneboxing so I checked from the command line using the “curl to the BBC site” mentioned above and it worked. So I knew that embed.rocks was live and recognising my credentials.
I tried disabling the plugin - and Oneboxes worked again - as they should because my new staging box isn’t blacklisted yet.
I re-enabled the plugin and still got the same problem - Oneboxes no longer worked.
Finally, I rebooted the server and it started working!
There’s a noticeable delay so I know the Onebox is going via embed.rocks, although, annoyingly embed.rocks’s dashboard seems to not update regularly enough (monthly?) to show my latest use of their service.
So, long story short, it LOOKS like that I needed to reboot / restart Discourse for the plugin to behave as expected.
I know this sounds unlikely, but I’m pretty certain about the behaviour I observed. Could it be something to do with the plugin monkey-patching the method thereby being ‘used’ even before enabling it?
Anyway, all good now so I just thought I’d share an odd observation.
1 Like
All bets are off I’m afraid: the plugin is sorely needing an update to latest Discourse codebase. I’ll get around to that soon.
Glad it’s working for you and some interesting insights!
I would definitely consider PR’s to add support for alternative services, but Embed.rocks seems very good value against the competition?
1 Like
To be honest, I only consider using embed.rocks when I need to re-cook lots of posts. Day-to-day volumes of embeds are normally OK.
As you say, it’s excellent value for that.
Good to know.
Great work, as always!
1 Like
Yesterday I caught up with core code and pushed an update:
But, tbh, most of this was just matching the code format, very little changed.
1 Like