Create embedable urls suitable for iframe incluson in a remote site

[brendanheywood]

Something along the lines of:

Start with: http://www.thecrag.com/climbing/australia/gara-gorge/upper-gara-gorge

then tack something on the end: http://www.thecrag.com/climbing/australia/gara-gorge/upper-gara-gorge?embed=1

which trims off some most of the nav just down to the main content. Then we wrap it in some iframe code and make a nice UI that people can cut and paste into their own servers:

There is a boiler plate JS that needs to happen to make the iframe resize resize to contain the content which can be a pain. Alternatively instead of an iframe we produce an embed code which inserts content into the same html doc (which often includes an iframe but with more control). Producing an embed code similar to GA, or the FB, G+ like buttons is not trivial (avoid XSS attacks etc, don't block loading of the remote site, etc), but there are some great resources I've been collecting:

http://css-tricks.com/thinking-async/ http://remysharp.com/2013/01/14/cors-isnt-just-for-xhr/ http://calendar.perfplanet.com/2012/the-non-blocking-script-loader-pattern/ http://calendar.perfplanet.com/2011/the-art-and-craft-of-the-async-snippet/

[brendanheywood]

After the debacle with the frame stuff in GA I'm defintely steering towards a script based include instead of an pure iframe solution.

[brendanheywood]

General idea, given a url of a photo, profile, topo, area etc we stick it into an iframe in a special way and you get a nice embeddable chunk of summary html, eg:

• [ ] an account url => minor/cardClimber (example in /climbers page)
• [ ] a photo url => minor/linkPhoto
• [ ] a topo url => minor/phototopo
• [ ] an area url => minor/cardArea (doesn't exist yet)

Almost no work, and just a wrapper around existing and future markdown stuff.

New url: www.thecrag.com/iframe?http%3A//www.thecrag.com/photo/12345

and possibly also just a param would give identical results www.thecrag.com/photo/12345?iframe=true

This would completely bypass the normal template process, and just load expandInternalLink function inside Markdown.pm, grab the html result and then pass it to a new template:

major/primarycontent/embed

This will wrap it in the barest html to make it work, probably just a link to the stylesheet and common.js to bootstrap topos etc if needed. If we want to go the extra step and make a script loader js chunk then it will wrap around this url anyway.

I really like the simplicity and consistency of just handing it of to the markdown system. If someone tries to embed a url that we don't handle, say a trip or publication, it will still work and just render as an a tag link.

See also: #833 for topo embed and #511 for photo embed

[scd]

I am not sure if I fully understand the exact steps (ie I could not sit down and implement right now).

If I understand things correctly when the production server gets one of these requests: www.thecrag.com/photo/12345?iframe=true

The server does not load the normal template, but instead loads a card file which is basically a minor template.

Could this also be done with an AJAX, just embedding the HTML using javascript. In the back of my mind I thought there were issues with iframes, so it has never been an option for me.

Some other things that may work in our favor for this one, every ID is unique across the board so something like: www.thecrag.com/card/1234 would be equivalent.

Knowing the table to lookup the ID would save a bit of processing so

www.thecrag.com/card/photo/1234

If this makes sense then I think I understand what it is you are getting at.

Thinking further this would work on external sites as well.

www.thecrag.com/card/climber/brendan_heywood

Ultimately, is this just badging?

[scd]

BTW there is possibly some confusion with my terminology inside Markdown.pm.

expandInternalLinks is used for matching route names and turning them into links.

actually expandExternalLinks is the the thing that will match www.thecrag.com/photo/1234.

What I think we need is something that will run before this called expandInternalCardLinks which will match predefined internal links.

Don't forget that our template system assumes that the template data has already been retrieved from the db. This means we also have to run some db retrieval functions in the expandInternalCardLinks function.

[scd]

Third thought - I think our activity and ascent logs could also be done this way, which would solve a few issues?

[brendanheywood]

On Tue, Feb 25, 2014 at 9:23 PM, Simon Dale notifications@github.comwrote:

I am not sure if I fully understand the exact steps (ie I could not sit down and implement right now).

If I understand things correctly when the production server gets one of these requests: www.thecrag.com/photo/12345?iframe=true

The server does not load the normal template, but instead loads a card file which is basically a minor template.

yup, for photos specifically we'd use the minor/linkPhoto template, but if it makes things easier we could make a bunch of new templates specifically for this maybe html/thecrag/embed/climber|area|photo etc, and they they can mostly palm it off to existing templates. Similar to the feeds templates

Could this also be done with an AJAX, just embedding the HTML using javascript. In the back of my mind I thought there were issues with iframes, so it has never been an option for me.

Yeah I entertained the ajax route and it is feasible but I think just embedding it server side will be a better end result. The markdown could just do some very basic sanitization and add a data- attribute and then let the front end optionally deal with it. The pro's are saving a few cpu cycles but you aren't really you just pushing them into another apache process with it's own overheads and will generally end up being more work.

And yes iframes are hairy but they are just another tool in the box if set up right. Almost every g+, facebook button, badge etc out there will use an iframe but not directly, you get a javascript snippet that creates the iframe in just the right shape.

Some other things that may work in our favor for this one, every ID is unique across the board so something like: www.thecrag.com/card/1234 would be equivalent.

yes, for embedding this would be fine, but in the forums and markdown this is essentially a non-starter because noone will ever cut and paste this url into a markdown field. I don't want to spend much time on the embed side, but I just think we can get it almost for free leverage the markdown stuff.

Knowing the table to lookup the ID would save a bit of processing so

www.thecrag.com/card/photo/1234

If this makes sense then I think I understand what it is you are getting at.

See above, yes technically it makes sense, but from a UX point of view it makes no sense at all.

Thinking further this would work on external sites as well.

I see the embedding as only for external sites.

For internal use inside a template we'd just call the right sub template, and for a link inside markdown it will be processed by markdown.pm which in turn goes to the same sub template. The only time we would use our own embed service is if we wanted to convert a link to a chunk via ajax instead of being done at inital render, but don't think there is much point, see second paragraph above.

www.thecrag.com/card/climber/brendan_heywood

Ultimately, is this just badging?

Yes this is synonymous with a badge on a 3rd party site, as say a climbers profile summary, or a crags summary

cheers Brendan

http://thecrag.com/

http://github.com/brendanheywood http://www.thecrag.com/climber/brendanheywood

[brendanheywood]

On Tue, Feb 25, 2014 at 9:45 PM, Simon Dale notifications@github.comwrote:

Third thought - I think our activity and ascent logs could also be done this way, which would solve a few issues?

Not sure exactly what you mean by this?

cheers Brendan

http://thecrag.com/

http://github.com/brendanheywood http://www.thecrag.com/climber/brendanheywood

[scd]

I have had a bit of a play with expanding links in Markdown. There is a circular perl module reference problem. Also Markdown is sometimes called within a Mason template and sometimes not. I think we have to sort out some circular logic before we implement this.

[brendanheywood]

This one is more or less done / redundant due to #1638 so closing this one