#1310 - oEmbed support (input) - Comments

This is a spacer post for a website comment topic. The content this topic relates to: #1310 - oEmbed support (input)

Rather than using that embed code, I like the idea of using oEmbed. Instagram don't advertise it in their pages but there is an oEmbed "endpoint" for Instagram photos we could let Composr know about...
http://api.instagram.com/oembed?url=http://instagram.com/p/byrmq5pgud

From that we can get the title and the URL to the image, to embed that image directly:
http://distilleryimage9.ak.instagram.com/7d55ed04ed6411e2a27d22000a9f165c_7.jpg

The advantage to this method is that we can then support all kinds of oembed services (although not completely out of the box, as we'd need to create a white-list feature [security reasons], and not all oEmbed services are discoverable, e.g. Instagram).

(Oh, I skim-read this issue too much. I didn't notice mention of news/forums and of twitter. I'll need to amend the initial hours I put in - sorry about that, although I am happy to look at it more comprehensively, as this does align a lot with oEmbed)

sounds like a nice overview upgrade. I'll take a couple weeks to see what our database syncing cost will be, and then see if this can be afforded at the same time

Worth investigating, maybe we can use a shared API, for instance:
http://ckeditor.com/addon/oembed

However you choose to implement, would be good to allow embedding of audio too

Thanks for the sponsorship :)! This is now under development. I thought the best way to approach this is actually to completely rebuild the internal API for gallery rendering, attachment rendering, and some aspects of Comcode rendering/syntax, and put it all back in with a new pluggable API that covers it all. This should be a much cleaner implementation, with automatic sharing of the benefit of any new media type implementation across different parts of Composr.

We have some good progress on this now. I am about 50% through internal API recoding, but I have oEmbed itself implemented.

The following services are tested to work:
youtube
vimeo
dailymotion
slideshare
scribd
flickr
instagram
photobucket
soundcloud
twitter
twitpic
imdb
wikipedia
cnn
Google maps
xkcd
imgur
tinypic

In theory though we can support anything embed.ly or noembed.com supports. It's just I have not configured/tested the more obscure services. Youtube-Twitter are supported via native oEmbed supported on those websites. Twitpic-Tinypic are via embed.ly/noembed.com (because the websites themselves do not have native oEmbed).

Autodiscovery works. So any website out there that has oEmbed with autodiscovery setup, will automatically work.

---

OpenGraph/Meta/Twitter Card parsing is also implemented. So pretty much any modern website will now show with a nice description rather than just a title. Often, with an image too (if meta tags for it have been defined).

sounds great

This is a list of other renderers we have (i.e. not going through oembed [oembed is implemented as just another renderer in the list])...
video_cnn
audio_general
audio_microsoft
audio_websafe
flash
hyperlink
image_websafe
pdf
quicktime
realaudio
realmedia
svg
video_facebook
video_general
video_microsoft
video_websafe
vimeo

Renderers are selected automatically via a scoring/qualification system.

This is now implemented.

Rishi, I will come back to this fairly soon with a deployment to your site.

I have done a partial backport of my changes to v9. This is the bulk of the experience (including galleries and direct link posting), but doesn't replace the attachment system's renderers with the new media rendering system and doesn't deprecate some old Comcode tags and add a new 'media tag'. This way, the value of the functionality is available, without messing too much with existing code. The 'clean up' part of this will come with v10, but 'cleaning up' is a future-minded thing, so that's fine.

This is now uploaded for you Rishi :). It seems to be running fine, but even with my caution, I am aware that I have just plugged a lot of new code that partly replaces existing behaviour of existing systems (that's why I waited a week, to make sure I did it at a point where I was well rested, and had had time to mull things over fully). So, if I accidentally put up any bugs, please let me know and I will fix them promptly.

(Other users - take note there is a v9 fork on github, "oembed")

Hello Chris,

I tried an example just now, not because I had planned to fully explore this yet, but because I was watching a video that I realized should be shared on our site. It's a ustream.tv video. What does work is that I can paste the video's embed code in a blog post and it appears. However if I use the Gallery entry screen and paste the video's link code (http://www.ustream.tv/recorded/39054773) in the URL field, I get an error and the message-- You did not upload a thumbnail and we failed to generate one automatically.

Hello,

Generally, you can now add pretty much anything as a video (even if it won't be handled as one as such). However, this would have shown with a hyperlink box rather than a video, and a thumbnail could not be generated automatically. The Composr definition of 'video' has now become very broad.

However, I have run some tests, and you can set up this site to run with oAuth.

I also got justin.tv working, another popular streaming site I had not previously considered.

Go to Admin Zone > Setup > Configuration > Feature options > Media

Add these to the oEmbed white-list:
ustream.tv
justin.tv

Add these to the oEmbed end-points:
(https?://(www\.)?ustream\.tv/.*) = http://www.ustream.tv/oembed
(https?://www\.justin\.tv/.*) = http://api.embed.ly/1/oembed

You may notice justin.tv is using embedly. The service does not directly support oEmbed, but embedly works here as a gateway (as it does with a lot of sites).

It is also worth me noting ustream.tv does not support auto-probing for oEmbed. For some sites this works and only the white-list needs updating (because the end-point is auto-detectable).

You may wonder why we don't white-list all that can auto-probe. It's for security. These sites pipe through HTML to your own, so we need to take care with what we will white-list.

neat. I've just added two videos successfully (and manually creating thumbnails)

I notice that if we add a video and it doesn't generate a thumbnail automatically, and so I go 'edit' the video entry to manually upload a thumbnail, the system doesn't acknowledge it (won't show the thumbnail in the gallery/carousel). The system only acknowledges it if I upload a thumbnail when creating the video entry in the first place.

Can you engineer things so that a thumbnail could be successfully added after the fact? I would imagine users running into this multiple times.

I tried adding a random twitpic to a gallery just now as a test (http://twitpic.com/dee18p) and it didn't work. Got error and message--

You did not provide an upload, or you tried to upload a file that is too large

twitpic gallery image upload now fixed :).

Regarding thumbnails...

I did manage to reproduce this, but found it was not a bug. I think I probably fell into the same trap you did. If you are viewing a flow-mode gallery, it will default to showing the most recent as the default focused video (if you haven't explicitly selected one yet).

If you therefore add a second video, the ones for choice in the carousel would switch around. Given that the thumbnails from ustream are very generic, it is easy to get mixed up about what is what.

thanks Chris.

Not sure if I conveyed the thumbnail question accurately, because I'm not really understanding your response. I meant, can things be engineered so that the user can go back into an existing video entry and upload a new thumbnail for it.

Yes. The thumbnail URL is under 'advanced' on the edit screen.