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!
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):
Update to keep up with Discourse resolving a breaking change:
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:
I’ve trawled this topic but can’t find anything that helps. Any suggestions?
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
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:
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?
Is there a facebook embed format with a facebook api key?
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
Are you sure that link is to a publicly exposed Facebook post?
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.
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.
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?
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!
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.