For an external Facebook Instant Article generator, we need the cooked HTML posts but without rendered oneboxes…
Does any such route or API endpoint for posts exist already?
AI-generated summary
The discussion is about finding a route to get cooked posts in Discourse without rendered oneboxes. Terrapop needs cooked HTML posts for an external Facebook Instant Article generator, but without oneboxes.
adopilot suggests a raw post button, but it doesn’t meet the requirements. neounix proposes writing a plugin to hide or remove the DOM element for oneboxes when the requesting User Agent string matches the User Agent string of the FB bot. sam mentions that post-processing the HTML is necessary as cooked posts already contain expanded oneboxes.
Terrapop explains that using raw posts and a PHP markdown parser doesn’t replicate the magic Discourse does to markdown, and they want to post-process oneboxes via Iframely. fzngagan suggests monkey patching the responsible method to exclude onebox generation, but Terrapop wants an endpoint that produces cooked posts without oneboxes, without changing the cooking behavior in general. neounix reiterates his suggestion to hide or remove the DOM element by matching the User Agent string and using JavaScript.
Maybe this can help GitHub - discourse/raw-post-button · GitHub
Hi @adopilot, many thanks for your feedback. Kindly can you elaborate?
Looks like a component to view the raw post.
We’re looking for something to render a cooked post, but without the oneboxes.
Apologies, i thought that you need raw post, later I did realised that I was wrong and it was posted allready.
Anybody? Can this somehow be achieved?
Hey @Terrapop
You could write a plugin to hide (or remove) the DOM element for the One Box when the requesting User Agent string matches the User Agent string of the FB bot.
Hope this helps.
You will need to post process the HTML, the cooked posts already contains all the HTML for oneboxes expanded.
That is exactly the problem. As the cooked posts contain the oneboxes (which don’t have the original media links anymore, only raw has the original links) we can’t transform them into a FB IA valid format.
Iframely is producing IA valid IFRAMEs from the standalone links. We tried to use the raw posts and use a PHP markdown parser (Markdown-It for PHP) plus Iframely for the standalone links, but the Discourse markdown parsing does a lot more, and we don’t want to replicate all the magic Discourse does to the markdown. Thus, we are looking for a route to get cooked posts, but without parsed oneboxes (as we want to post-process those via Iframely instead).
Our current approach works for simple posts ie. take raw as a basis, use PHP Mardown-It to transform into HTML, and use Iframely to produce IA valid media cards (oneboxes aren’t), then transform the HTML into Facebook IA HTML and transmit via the FB PHP SDK, but as Discourse applies a lot of additional rules to the markdown parsing, it would be great to somehow get the parsed HTML directly from Discourse, but just without the oneboxes.
You don’t need to cook you post outside discourse. Just monkey patch the responsible method and exclude the part where oneboxes are generated. General idea.
Well, we don’t want to change the cooking behavior in general on Discourse but need an endpoint (API) that produces a cooked post but without oneboxes (but leave the original standalone links inside e.g. as ahrefs).
Just hide or remove the DOM element. It’s quite a simple task.
- Match User Agent string with Ruby and set a boolean on a match**.
- Javascript to hide the DOM element if the boolean is true.
This is basically the “standard” way to do this and similar tasks where a developer does not want to show (or wants to remove) any DOM element.
**Note:
Using the ‘gon’ Ruby gem makes passing any Ruby variable to Javascript very simple, but I have only used it on a Rails app, not with EmberJS in the stack (anyway, there are many ways to pass a Ruby variable to JS)..