Last modified: 2013-09-29 14:19:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T27269, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25269 - Add support to embed commons videos in wikimedia blogs
Add support to embed commons videos in wikimedia blogs
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Blog (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 25854 25862 27699
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-23 18:15 UTC by Michael Dale
Modified: 2013-09-29 14:19 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Michael Dale 2010-09-23 18:15:32 UTC
Presently there is now way for us to 'embed' videos from commons in our blog posts. We don't simply want to reference the video files since it can include community translated subtitles. To address this mwEmbed includes a "share button": 
http://commons.wikimedia.org/wiki/File:Nice_People_MEDIUM.ogv?withJS=MediaWiki:MwEmbed.js

But the <object> tag it produces is striped by wordpress on saving the blog post. 

It would be fairly trival to either 
a) add a handler to our config:
http://codex.wordpress.org/Function_Reference/wp_embed_register_handler
or 
b) Create a wordpress 'commons embed' plug-in

If this is something we want to do, and will be installed once I create it, I will make it happen.
Comment 1 Brion Vibber 2010-11-09 23:50:57 UTC
Looks like WordPress will handle embedding info exposed via oEmbed, which I'm working on over on bug 25854.

The URL schema will still need to be whitelisted though on the wordpress instances: http://codex.wordpress.org/Function_Reference/wp_oembed_add_provider but that'd avoid having to special-case the configuration with details of how the embedding works.

Adding bug 25854 as a dependency for this bug.


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.
Comment 2 Michael Dale 2010-11-10 16:01:24 UTC
I agree ;) .. The TimedMediaHandler adds support via custom display type to the page url so it would be something similar to "printable" url parameter that make the page "only display" the player. 
<iframe src="http://commons.wikimedia.org/wiki/File:Nice_People_Medium.ogv?iframeplayer=yes"></iframe>

We can do away with the height width and just have the iframe take up 100% of its window per some of the iframe proxy work I have done for kaltura side of mwEmbed usage: 
http://www.kaltura.org/apis/html5lib/kplayer-examples/Player_IFrameResizable.html

The iframe system is better and quickly replacing "object" since it supports a cross domain messaging system for emulating video player api,  can also work without any hosting page js and can seamlessly switch between flash and html5 players ( important once Adobe ships vp8 / WebM in flash ) 
The "industry" is moving toward iframe embeds ie youtube
http://apiblog.youtube.com/2010/07/new-way-to-embed-youtube-videos.html and others.

What I suggest in the mean time to support iframe embed is the following:

<iframe src="http://commons.wikimedia.org/wiki/File:Nice_People_Medium.ogv?iframeplayer=yes&withJS=MediaWiki:MwEmbed.js"></iframe>

We already have a lot of these withJS links floating around so once we and update to the html5 player extension ( Timed media handler ) the gadget will know to let the extension take over. At that point we can stop appending the js url param, but if the withJS is included or not it the embed urls will remain valid into the future. 

If we need to change the url that hosts the mwEmbed javascript payloads we can do that easily just by modifying the MediaWiki:MwEmbed.js page. For example copying a static version to be hosted on cluster servers via mediawiki js page ( like other gadgets ).
Comment 3 Thehelpfulone 2012-05-01 14:30:47 UTC
Is this still required? I can see that the last time videos were used (as far as I can tell) was http://blog.wikimedia.org/2010/09/21/who-edits-wikipedia/ and the 4 blog posts with those images. It's common place to link to videos on commons instead at present, as you can see at http://blog.wikimedia.org/2012/04/12/wikimedia-highlights-march-2012/ for example.
Comment 4 Michael Dale 2012-05-01 17:11:28 UTC
I think supporting the feature is important regardless if its used in a particular blog post or not, so that folks have the option to use it in the future if they want to.
Comment 5 Guillaume Paumier 2012-08-12 19:25:20 UTC
Reset assignee to default as this is not within my area of focus any more.
Comment 6 Sage Ross 2012-11-09 19:36:53 UTC
This appears to be partially done... there is indeed a video embedded in a blog post announcing the deployment of TimedMediaHandler:

http://blog.wikimedia.org/2012/11/08/introducing-wikipedias-new-html5-video-player/

However, the embedded video is a rather worse experience than videos on-wiki. The controls are limited, and at the end, there is a Kaltura logo which you can click on, and it loads the the corp.kaltura.com homepage into the frame of the embedded video. Aside from that behavior being broken, I don't like that videos embedded from Wikipedia are essentially serving a Kaltura ad at the end.
Comment 7 Helder 2012-11-09 19:51:40 UTC
(In reply to comment #6)
> embedded video. Aside from that behavior being broken, I don't like that videos
> embedded from Wikipedia are essentially serving a Kaltura ad at the end.

Is that bug 23965? (https://bugzilla.wikimedia.org/23965)
Comment 8 Sage Ross 2012-11-09 19:56:34 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > embedded video. Aside from that behavior being broken, I don't like that videos
> > embedded from Wikipedia are essentially serving a Kaltura ad at the end.
> 
> Is that bug 23965? (https://bugzilla.wikimedia.org/23965)

It does seem to be the same thing, although the Kaltura logo and link are not actually displayed with the on-wiki player (that I've seen).
Comment 9 Michael Dale 2012-11-09 19:59:00 UTC
The controls issue should be fixed with: 
https://gerrit.wikimedia.org/r/#/c/32460/2
Comment 10 Brion Vibber 2013-09-29 14:19:27 UTC
Seems resolved? I'm closing this out as fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links