Page MenuHomePhabricator

Need stable URLs for media embedding (video players: OggHandler, mwEmbed, etc)
Closed, ResolvedPublic

Description

Bug 25269 mentions needing a way to embed Commons videos into WordPress blogs; once whitelisted, the embedding information can be exposed to WordPress via oEmbed (bug 25854) -- however currently we don't have stable embedding code.

Embedding in arbitrary sites is currently done using an experimental setup built around the mwEmbed player, which isn't actually fully set up natively on Commons etc. The result is that the embedding HTML code includes unstable URLs referring to a prototype site with a bunch of mwEmbed-specific paths in it.

I think we'll want to have a stable URL on the wiki for the referenced object for the embedding; then we can expose _that_ and let the wiki worry about whether it needs to pull in OggHandler, mwEmbed, or whatever is appropriate *at view time* based on presently-deployed tech and file formats.

My notes on this from bug 25269:

The embedding HTML currently exposed via the MwEmbed JS stuff seems pretty
weird:

<object
data="http://prototype.wikimedia.org/mwe-gadget/mwEmbed/remotes/../mwEmbedFrame.php?apiTitleKey=Nice_People_MEDIUM.ogv&apiProvider=commons&skin=kskin&durationHint=86&width=640&height=360"
width="640" height="382" style="overflow:hidden" ></object>

We probably want to have stable embedding URLs that'll use whatever the current
appropriate technology is -- since the references will be used in blog posts
etc on other sites, they'll need to be stable and functional over a period of
many years. That means avoiding test hostnames and hardcoded extension paths.

The above even isn't even referencing the core servers, so I'm assuming this is
a whole bunch of custom JS stuff that isn't accessible within MediaWiki itself,
such as to generate the embedding code direct from MediaWiki... what's the
story on this currently?

Might want to see something more like this:

<object
data="http://commons.wikimedia.org/wiki/Special:EmbedMedia/Nice_People_MEDIUM.ogv?durationHint=86&width=640&height=360"
width="640" height="382" style="overflow:hidden" ></object>

The embedding URL should stay the same whether we're currently using
OggHandler, mwEmbed, or some unrelated video format handler to display the
file.


Version: unspecified
Severity: enhancement

Details

Reference
bz25862

Event Timeline

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz25862.
bzimport added a subscriber: Unknown Object (MLST).
brion created this task.Nov 9 2010, 11:57 PM

Bryan.TongMinh wrote:

Depends on bug 26741; presumably the fix of that bug will be mimicking the page/revision tables for image, resulting in a file_rev_id which would fix this bug as well.

mdale wrote:

If you press the "use on the web" button on commons now you get:

<iframe src="http://commons.wikimedia.org/wiki/File:Folgers.ogv?withJS=MediaWiki:MwEmbed.js&embedplayer=yes" width="240" height="180" frameborder="0" ></iframe>

This works in blogs like so:
http://wikimediavideotest.blogspot.com/

The format is explained in bug 25269 .. direct reference to the prototype urls have been removed, and an updated extension will handle the 'embedplayer=yes' parameter.

It now has code like: <iframe src="//commons.wikimedia.org/wiki/File:What's_a_Love_Dart?.webm?embedplayer=yes" width="800" height="450" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>

Does that make this bug fixed?

mdale wrote:

yes. This can be closed as soon as the other iframe bug 50617 fix is deployed it should work again.

(In reply to comment #4)

yes. This can be closed as soon as the other iframe bug 50617 fix is deployed
it should work again.

That fix was deployed earlier today.

Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles raised the priority of this task from Normal to Unbreak Now!.
Gilles lowered the priority of this task from Unbreak Now! to Normal.Dec 4 2014, 11:21 AM