What it does
Turns this kind of result:
(where your server has failed to bring back the page source so cannot extract the required tags to build the onebox)
It simply provides an alternative path for onebox to get its page source with which to look for meta-data when the target server refuses your connection.
It changes nothing about how onebox then processes the page source to find the meta-data and render the box.
It’s meant to allow you to enter the details and credentials of a third party API to bring back the page instead of doing a normal http call directly to the target page.
I found my servers were being forbidden access to a number of commercial sites so oneboxes would fail to be rendered. It essentiallly helps leverage the trustworthiness of the 3rd party API, a bit like a mail service.
Why it’s cost effective
It is intended to use the API sparingly and will bring back the page source in the normal way under most circumstances. It only uses the API when it’s refused a response.. On deeper investigation and with experience I’ve noticed that using the API every time may be a requirement now as the redirects stage can fail to bring back the correct page for the very same reasons as a total denial to respond. The plugin can now use the API on every occasion.
What this means is you can use a relatively cheap VPS but still get reliable one-boxing functionality, even if your IP or user agent is somehow ‘blacklisted’.
You don’t need it if
You are oneboxing all your target content ok with the vanilla install and all users are happy
You need an account with a suitable 3rd part API.
See example below
This setting allows you to ignore the prefetch (to check if the direct crawl returns a result) and use the API from the get-go.
I recommend setting this to TRUE.
This is more expensive of course but often yields better results as there are some cases where the pre-fetch gets redirected to the wrong page because you are not trusted.
It’s only been tested with one provider at the moment and not tested on others. That provider is https://embed.rocks (with whom I have no affiliation). I’m happy to consider supporting more services if the work is sponsored.
The monkey patching is done at method level. This overrides more code than it needs to which leads to a greater risk of the plugin breaking after a core update. However I don’t think there’s a way to minimise this further?
All feedback welcome. Please it on GitHub if you find it useful.