-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes needed due to new oEmbed Read #14
Comments
Thanks for opening this issue.
It's not ready, and I don't think the new review process is any easier as
it requires manual review.
I will be working on a new version in coming weeks. I'm leaning to a plugin
that I put a server to deal with a single app, and the plugin uses this
server to get the embed content, avoiding the app review requirement.
|
For those of us who already have approval for Read, I think the modification that would need to be done is pretty simple – you'd just need to store an additional string (client token, which is generated by FB just as the app secret is, you don't even have to make an additional request for it) alongside the app ID and app secret (you might not even need that) you're already storing. After that the
This is how I read the oEmbed Read docs, anyway – if it's more complicated let me know ... |
I don't think this is relevant, as the processing of the [original post URL] > [oembed content] happens backend, and not from the end users browser. The client_token use case is for when the end user will be making the request, which is not the case here, thus not applicable. |
Thanks for replying – you're right, I was confused about what was happening. Turns out that as long as you have 'standard access' to oEmbed Read via an FB app the app secret, and the current version of the plugin, continue to operate just fine (I assume 'advanced access' is where the client token would come in). |
Some bare urls work, some don't (it's not per-post embed permission settings either) – I'm not sure what is happening, I'm going to rework embeds to wrap bare urls with iframes. I wish I knew what was going on and how to solve it; I'll keep an eye on this project to see how development goes. |
Sincere apologies for being terse earlier; my frustration is a lot more with FB than with the plugin (speaking of plugins, FB still says in their docs they're making a WP plugin, bit dubious) ... After testing for a bit, I can confirm that 'advanced access' is indeed what you need to get oEmbed html back from FB endpoints, and that the app id+secret is all you need for that. 'Standard access' to oEmbed Read won't do it – when you go through app review, give the mods a url of where you'd like your embeds to appear ('Provide detailed step-by-step instructions on how a reviewer can test your integration'), along with the url of one of those embeds ('Please provide a URL where we can test Oembed Read'). It was ok in my case to demonstrate what i wanted to achieve with access, instead of showing them actually working embeds on one of my pages. |
HI Colin, please can you provide some more info as I sumitted with a URL where I want to display it but I have no clue what else they want and failed twice again so any help or details how to do the submission for review would be appreciated. |
Sure – first let's recap what we're trying to do; this may be obvious but just in case anyone else reads this maybe it'd be helpful. oEmbeds are kind of magic, and it's easy to forget how it all actually works and what problems it's trying to solve. We want to take some url on somebody else's service and embed it on our page. We could create an iframe ourselves, but then we're fiddling with a sometimes very large chunk of html stuck in our page and we're maintaining that forever. What if the embed needs to change somehow in future (becoming fluid and not fixed-width, maybe)? Also we're asking for that embed every time our page loads, that's a lot of requests our page has to make. What if the service (a 'provider') could send us prerendered html for that url we want, so instead of an iframe or chunk of html in our content, we have a reference to a cache of that html in our site and the service can send us what that embed html should be? That's the idea behind oEmbeds. WP registers a bunch of oEmbed providers – as it renders content, it checks for urls (regex patterns) in certain formats and if it finds one, that triggers a request to that provider to see if it can get some html it can cache (you can change those providers, or even add your own). FB doesn't mind you doing this, but it wants us to get permission for it beforehand so it can connect you with what you're doing with their API, unlike other providers. So we need an FB app, with a domain set to our site's domain, which has 'advanced' permission to 'read' oEmbeds (I'm still unclear on what exactly 'standard' permission allows, if anything). We're going to need credentials to send along when we ask for an oEmbed response: the FB app's ID, and its secret which are found in 'basic' settings for that app. So who do we now ask for that html? In IG's case we make a GET to: (If you have an http client like Postman, Insomnia, or my favorite Paw you can more easily look at what you're sending and what FB is responding with.) What we expect FB to pass back to us in the response body is json containing a heap of info about the embed, like its author, dimensions, thumbnail images – and most importantly for us, a big wad of html. (If you do not get a 200 response with that stuff included, you'll instead get a 400 with an error message telling you the embed isn't allowed – either because the post has been marked private, or that your app doesn't have permission to do this at all yet.) That html is going to get saved to post meta by WP with a key of If instead you got back a 400 with no html you can cache, you're going to end up with the dreaded Ok, so how do we get FB to let us do this? You'll need to open an app review in your FB app, asking for advanced access to oEmbed Read. In the first section ('Provide detailed step-by-step instructions on how a reviewer can test your integration') say you're trying to use oEmbeds, and provide a specific url of a page on your site you want to put an embed on. Then in the next section, which isn't very clear about what it really wants ('Please provide a URL where we can test Oembed Read') give them the FB/IG url of what you're trying to embed. If they reject you, it's most likely that the mods are confused by how you worded things, not that they consider you hostile or anything – you can always ask again. Also, requests are handled by different people on different days, and they look at other data relating to your site which informs their decision, so in some cases you may have to ask a couple of different times in slightly different ways, or correct some other problem they have with you. But for this particular thing – caching oEmbeds – you're not asking for much, there's not a big reason for them to contest it. Beyond review, all this stuff – checking for FB and IG urls in your content, making requests for oEmbed html with your credentials, caching them – is handled by the oEmbed Plus plugin. There are a number of different endpoints to hit and regexes for urls for FB and IG, and that's all kept track of (they might change once again!). As of this writing the plugin's using v8.0 of the FB graph api; ideally, your FB app should be at the same version or above, so check that. |
I'm no longer actively needing this, so closing this out as it's 3+ years old and there is info on solution above |
Facebook alerted us that oEmbed Read is replacing oEmbed with a new app review need, amongst other changes.
Is the plugin ready for this or any updates needed?
https://developers.facebook.com/docs/plugins/oembed/
The text was updated successfully, but these errors were encountered: