This is just a test

Yep, it like I thought. Github changed the format of the iframe they use so onebox cant display it any more.

Oh, no! Sorry to hear that they did that. :frowning:

That has happened for several other oneboxing cases too. I think discourse have given up dropbox fighting inclusion; there you could argue that dropbox didn’t want their files oneboxed. But google photos broke oneboxing videos as well, and discourse ended up replacing with just linking out to an external player; there I think oneboxing was just collateral damage from some other change.

2 Likes

Yeah, while testing some changes I made to onebox on my development setup, things didnt look quite right so I thought I’d test it here.

I don’t think it would be that hard to fix the display of the github iframe. It just depends if they did it on purpose.

2 Likes

Oh well, but great choice of test material. Nophead is a legend, IMHO.

2 Likes

I stand corrected.

Github did change the way they are calling their renderer but the old way of calling it still works.

The reason the github blob engine doesnt display is because discourse has added a security option that blocks iframes.

Screenshot from 2020-11-28 02-46-33

You have to add the “render.githubusercontent.com” line to allow it to work. Otherwise the “src=” attribute gets converted to a “data-unsanitized-src=” attribute.

I figured this out while trying to write an engine to handle 3D model files. I was trying to pass in a dataurl of the format “data:text/html;base64,” but it doesnt like that at all. :slight_smile:

Adding “data:” to the allowed iframes src got me past the converting src to data-unsanitized-src but then something else removes the src attribute complete. I assume another security feature. I get the feeling people don’t like the idea of embedding a custom webpage in a dataurl. :slight_smile:

So @mcdanlj, how would you feel about hosting a renderer page like the one github uses which could then be called with the url (local or remote) of a model to display? I think that would be a lot simpler to implement.

1 Like

That’s a perfectly reasonable iframe to allow. I’ve added it. It’s not rendering the contents internally for me, though, it just gets one step further.

Hosting a separate renderer page wouldn’t be hard, and we could deploy it with netlify or gitlab pages (both of which put arbitrary assets of reasonable size behind a CDN) without too much difficulty; I already do that for a couple of makerforums sites. Adding one for something like render.makerforums.info wouldn’t be hard. Perhaps I could deploy the site within the makerforums.info domain? That seems like it would be an easy enough decision. Presumably the rendering plugin could have configuration for where the renderer lives; I would think that would make development easier anyway.

However, it feels like it ought to be simpler to just embed it directly. If you haven’t already, it might be worth asking on meta.discourse.org if there is a plugin that models how to render an additional type of content from uploads. :slight_smile:

2 Likes

Good luck figuring that out.

I have not checked this site for ages. I figured I would look around again and see what I have been missing.

1 Like
3 Likes

So at least that works now.

3 Likes

Aha. I just clicked “rebuild HTML” on the OP and now it works as well. Didn’t realize I’d have to do that after adding the iframe configuration.

4 Likes

Ah. Good. You folk got it working again. Cool.

2 Likes