Make WordPress Core

Tagged: media Toggle Comment Threads | Keyboard Shortcuts

  • Scott Taylor 9:57 pm on April 8, 2013 Permalink
    Tags: Audio, media, MediaElement, , ,   

    Audio / Video support in Core 

    Post Formats are a big feature in WordPress 3.6. What you may not know is: there is now native support for Audio and Video in core! There has been great support for embeds by way of WP_Embed and oEmbed providers for a while, but, if you wanted to play an MP3 from your Media Library, you had to install a plugin. Supporting audio and video in core gives bands, podcasters, vloggers, et al the ability to easily and beautifully expresses themselves through sounds and moving pictures without using an external service.

    How does this work?

    At the core of the experience is the fantastic library, MediaElement.js. MediaElement is the facade layer that gives us maximum file support and cross-browser compatibility. While some libraries require a Flash-only solution to make your media work cross-environment, MediaElement lets you use HTML5 audio / video tags in every browser, and, only when necessary, will use a Flash or Silverlight plugin in the background to make incompatible media work. Translation, things like this: <audio> tag works in old IE, Windows Media files work in Chrome.

    MediaElement uses the same HTML markup, regardless of playback implementation, and you can use CSS to skin the players.

    Shortcodes

    MediaElement’s great, but we don’t want to be locked in to one external library forever. Instead of using MediaElement-specific markup everywhere, we expose audio and video markup through shortcodes: [audio] and [video].

    For the following scenarios:

    • I have an old post that has a video in the Media Library attached to it, and I want to use the new shortcode: [video]
    • I have the URL for a video, from the Media Library or external, that I want to play:
      [video src="video-source.mp4"]
    • I have a source URL and fallbacks for other HTML5-supported filetypes:
      [video width="600" height="480" mp4="source.mp4" ogv="source.ogv" webm="source.webm"]

    Same goes for audio:

    • I have an old post that has an audio file in the Media Library attached to it, and I want to use the new shortcode: [audio]
    • I have the URL for an MP3, from the Media Library or external, that I want to play: [audio src="audio-source.mp3"]
    • I have a source URL and fallbacks for other HTML5-supported filetypes:
      [audio mp3="source.mp3" ogg="source.ogg" wav="source.wav"]

    Shortcodes focus on the “what” and abstract the “how.” If you want to use a library that is not MediaElement, you can! Just look at what to filter: here

    Embeds

    There are also new embed handlers for audio and video. Using them is easy as dropping a media link on a line by itself in the editor:

    http://my.mp3s.com/cool/songs/coolest.mp3

I like this song because it is really cool!

    Works for both audio and video with URLs matching the allowed (and filterable) list of extensions (see: here and here)

    Admin

    Using the new post formats UI, it is even easier to get directly at the audio and video in your Media Library. When selecting, the media modal opens to your library, filtered by media type.

    Metadata

    In previous versions of WP, you could upload audio and video, but we were not generating metadata like we do for images. In 3.6, using the getID3 library, we are able to extract data from audio and video like cover art, song length, artist, album, song title, genre, codec, etc. It’s pretty great. We will soon be exposing more of this data in the admin as well, along with inline previews on the Edit Media page:

    Themers

    Themers can get in on the action, too, using structured-post-formats in their theme (Twenty Thirteen is a great place to look). The admin gives users flexibility when associating media with a post. the_post_format_audio() and the_post_format_video() will automagically retrieve and output your media in the front end.

     

    • sourceforge 10:09 pm on April 8, 2013 Permalink | Log in to Reply

      thank you, is this the html5 vid player? looks good, newer java based audio player is also needed, flash is always prone to attacks

    • Manny Fleurmond 10:11 pm on April 8, 2013 Permalink | Log in to Reply

      How does this handle m4a files?

    • Konstantin Obenland 10:59 pm on April 8, 2013 Permalink | Log in to Reply

      The attentive reader might have noticed how the buffer- and play-time-bars in the first and second screenshot have different colors.

      Themes can style these elements of the players. The first example is a screenshot from Twenty Thirteen, with a white buffer bar, an orange play time bar and no border-radius.

    • John Saddington 11:11 pm on April 8, 2013 Permalink | Log in to Reply

      this is fantastic. john dyer’s MEJS is amazing.

    • AK Ted 11:32 pm on April 8, 2013 Permalink | Log in to Reply

      This is great news! Can’t wait for stable to play with, no time atm for beta. :(

      Small grammar correction: “ability to easily and beautifully expresses themselves” (in first paragraph), should be “express”.

    • Michael Beckwith 11:51 pm on April 8, 2013 Permalink | Log in to Reply

      That’s pretty hot

    • Ipstenu (Mika Epstein) 1:07 am on April 9, 2013 Permalink | Log in to Reply

      What’s the fallback? Like if I use and they don’t allow for HTML5 (yes, I have people who don’t), what shows? Right now I made an html5video shortcode that has, at the bottom ‘Can’t see a video? Click here…’ and it defaults to the MP4.

      • Scott Taylor 2:47 am on April 9, 2013 Permalink | Log in to Reply

        I am pretty sure MP4 will win and play via Flash. If no flash and no HTML5, there will be a link that goes straight to the file.

    • Jon Brown 1:09 am on April 9, 2013 Permalink | Log in to Reply

      Not sure how I missed this on trac, but “YAY!!! & Oh No!!!!”.

      I just spent a month (not continuously) trying to figure out why MediaElements.js conflicted with Soliloquy (Flex based Slider) when both appeared on the same page on mobile. Only on mobile, everything worked fine everywhere else. I finally gave up, ditched ME.js for Video.js.

      I’m now about to test that site on 3.6 just out of curiosity as to what happens.

      I too really dislike this using shortcodes and my bigger concern is what this does to other plugins that use the shortcode already.

      Always seemed to me WP ought to follow best naming practices and use [wp_gallery], [wp_video], etc…

      • Jon Brown 1:26 am on April 9, 2013 Permalink | Log in to Reply

        That was easy to test… still conflicting somehow. I’ve let Thomas know with urls to dev/staging/live servers showing it all. It’s really bizzare that it only happens on mobile browsers (iOS chrome and safari) anbd throws no errors. Either works fine on it’s own, and we’ve recreated it on vanila WP running 2010.

    • Beau Lebens 1:42 am on April 9, 2013 Permalink | Log in to Reply

      <3

    • Tomas 4:01 am on April 9, 2013 Permalink | Log in to Reply

      WoW! This is good news!

    • Robert Chapin (miqrogroove) 1:48 pm on April 9, 2013 Permalink | Log in to Reply

      That’s hot! :D

    • redwallhp 10:35 pm on April 9, 2013 Permalink | Log in to Reply

      Awesome! The assimilation of the Crowd Favorite post format UI and MediaElement.js support in one version.

    • Eric Andrew Lewis 11:18 am on April 10, 2013 Permalink | Log in to Reply

      Totally wow.

    • hearvox 12:22 am on April 11, 2013 Permalink | Log in to Reply

      any hooks yet for skinning the default MEjs player?

    • rilwis 2:22 pm on April 11, 2013 Permalink | Log in to Reply

      This feature is really great and useful for all people. I’ve been using MEjs and it’s really great. Nice UI, great support.

    • johndyer 10:48 pm on April 11, 2013 Permalink | Log in to Reply

      So glad to hear it! Glad to have “contributed” :)

    • Maor Chasen 6:15 pm on April 12, 2013 Permalink | Log in to Reply

      Love!

    • Anderton 9:06 am on April 15, 2013 Permalink | Log in to Reply

      Have been playing around with it while developing a couple of themes for 3.6. It’s lovely, and easy to style. Have been using MediaElements,js before, and when i found out that it would be included in the Core, i was thrilled. Good move!

    • Bjarni Wark 10:25 pm on April 16, 2013 Permalink | Log in to Reply

      Really good news, thanks for the efforts of making this happen.

    • Maeve Lander 4:58 am on April 17, 2013 Permalink | Log in to Reply

      Just wondering how will this affect existing audio/video plugins? Any potential problems, conflicts, things plugin developers could do better to integrate with this etc?

    • esmi 7:49 pm on April 17, 2013 Permalink | Log in to Reply

      I have to say, I’m really disappointed that there’s no mechanism for people to add captions for videos or provide text transcripts with audio files. come on, people! We need to be encouraging people to do this kind of stuff but unless WordPress provides the methods, it just won’t happen.

      • Scott Taylor 7:57 pm on April 17, 2013 Permalink | Log in to Reply

        #patcheswelcome

      • Ipstenu (Mika Epstein) 8:18 pm on April 17, 2013 Permalink | Log in to Reply

        Speaking as someone totally ignorant of this, how DO you add captions to videos? Can I include a transcript.txt file like I do for different video versions?

        • Joe Dolson 11:26 pm on April 17, 2013 Permalink | Log in to Reply

          There are various formats for captions, but yes, essentially it amounts to referencing a text file with captions. Mediaelement.js supports .srt and .vtt caption formats, and they’re referenced as

          In this context, you should treat the terms ‘subtitles’ and ‘captions’ synonymously, although technically they are different.

          All the WP system needs to do for captions is provide a mechanism to upload them and auto-generate the relevant track elements, basically.

    • esmi 8:11 pm on April 17, 2013 Permalink | Log in to Reply

      We’ve only just picked this up in the make.wordpress.accessible group but, yes, we will be trying to come up with some patches if we can :)

    • FranciscoAMK 8:19 pm on April 21, 2013 Permalink | Log in to Reply

      Is the featured image set as the “poster” for the video post format?

  • Jen Mylo 9:11 pm on October 8, 2009 Permalink
    Tags: , media   

    Some media upload sketches.

     

    • Simon 4:38 pm on November 5, 2009 Permalink | Log in to Reply

      What happened to these? I’m guessing they won’t make 2.9? 3.0 instead?

  • Andrew Ozz 3:59 am on September 26, 2009 Permalink
    Tags: , media   

    Image Editor 

    The “first run” of a simple image editor has been in WordPress 2.9-rare for about two weeks. It lets the user crop, flip and rotate an image. It also has an option to scale the original (largest) image and to restore the originally uploaded version. There is a multi-step undo and redo support. Changes can be applied to all image sizes or only the thumbnail. The initial code is by Stephan Reiter author of the Scissors plugin.

    Currently when saving an edited image all previous intermediate image sizes are kept and the meta data for them (filename, width, height) is moved to another postmeta field. This is necessary to avoid breaking any posts or pages where the image was inserted. The editing workflow (multi-undo, preview of each step) makes it unnecessary to edit an image more than once or twice, however if an image is edited 6-7 times the backup files would be 25-30.

    There are couple of ways to avoid keeping unnecessary images, we could either track when an image was used in a post or a page, or we could have “standard” names for the intermediate image sizes. Tracking image use can be somehow problematic considering all the different ways content can be published in WordPress.

    Renaming the resized images from [imagename]-150×100 to [imagename]-thumbnail, etc. seems the more viable option. This would also bring instant image updates in already published posts, however may also have some compatibility problems with plugins that expect the image size to be part of the filename.

    Trac ticket for the image editor, suggestions and patches welcome :)

     

    • Alex (Viper007Bond) 5:02 am on September 26, 2009 Permalink | Log in to Reply

      You could also just use a shortcode for the image tag, although that may not be as user friendly. Then again, if you move domains, URLs, etc. you wouldn’t have to edit the post.

      So instead of this:

      &lt;img src=&quot;http://blog.com/wp-content/uploads/imagename-thumbnail.jpg&quot; width=&quot;150&quot; height=&quot;100&quot; title=&quot;Cool image&quot; alt=&quot;ohai&quot; /&gt;

      You’d do this:

      [image id=&quot;123&quot; size=&quot;thumbnail&quot; title=&quot;Cool image&quot; alt=&quot;ohai&quot;]

      The URL, width, and height would all be dynamic and change if you changed the thumbnail size, etc. This is opposite of now where even if the filename didn’t contain the dimensions, you’re still left with hard coded width/height parameters in the image tag.

      • scribu 11:49 am on September 26, 2009 Permalink | Log in to Reply

        That would be nice. And it’s been requested several times in the past.

      • Xavier 4:47 pm on September 26, 2009 Permalink | Log in to Reply

        • Beau 9:30 pm on September 26, 2009 Permalink | Log in to Reply

          Since both uploads would have a unique id in the DB, it doesn’t matter if they have the same filename. The correct URL would be output dynamically, based on wherever it was stored (as referenced by the DB)

      • Andrew Ozz 12:57 am on September 28, 2009 Permalink | Log in to Reply

        Think this came up when we were doing the captions shortcodes a year ago and was rejected. Perhaps we can look at the pro & con again. Since all movies and other embeds will be handled by shortcodes it may make sense to extend that to include images too.

        However I see a possible problem with that. The img tag doesn’t need any processing on display but a shortcode would need quite a lot as it seems we will have to do get_post() for the attachment. Also our shortcode parsing code/API doesn’t seem optimized enough to handle large quantity of shortcodes.

        • aarondcampbell 8:20 pm on October 3, 2009 Permalink | Log in to Reply

          It is true that it can’t handle really large posts with lots of shortcodes. However, that’s definitely only affecting a very small percentage of people (if we’re really focusing on the 80-20 principle, it’s less than 20%). Do we really think that enough people will be writing stuff this long (and putting enough shortcodes in it) that we should worry about it? (That’s the post where I first ran into the issue…I tried to explain that it was just too long, but apparently it’s quite effective as it is).

          I like the shortcode idea.

        • Andrew Ozz 2:31 am on October 5, 2009 Permalink | Log in to Reply

          True, this is very rare at the moment but turning img tags into shortcodes would increase that number, perhaps a lot.

          No, don’t think we can apply the 80/20 principle here. Would that mean we can break up to 20% of all published posts? :)

          The problem is that even a shorter post with a lot of images will reach the backtrack limit or be very slow to display.

        • DD32 2:58 am on October 5, 2009 Permalink | Log in to Reply

          > or be very slow to display.

          Reminds me of the mention of storing filtered post contents along side the raw and serving those up instead of applying the expensive filters every load..

        • Andrew Ozz 3:19 am on October 5, 2009 Permalink | Log in to Reply

          Yes, post_content_filtered is still in the posts table. Think there are few plugins that do this, not sure how well though as it bypasses all ‘post_content’ filters.

        • Alex (Viper007Bond) 3:38 am on October 5, 2009 Permalink | Log in to Reply

          Perhaps storing a partially cached version would be best, i.e. just internal shortcodes. You’d break a lot of plugins if you rendered the entire content from a cached copy.

      • Jonathan Dingman 9:22 pm on October 1, 2009 Permalink | Log in to Reply

        Would that imply dynamic resizing?

        ie, if someone changed the thumbnail size after already uploading the image, would it resize on the fly? (if specifying a thumbnail in the shortcode)

      • Denis de Bernardy 11:14 pm on October 3, 2009 Permalink | Log in to Reply

        Using a shortcode here would hammer the DB unless it’s properly implemented.

        And this “it hammers the database”, btw, is the reason I had opened:

        http://core.trac.wordpress.org/ticket/10882

        I use similar code in two plugins of mine, and since you can’t rely on an attachment from being tied to a single post, I check for a post meta to make sure there are attachments (and which ones) before tossing a query.

      • Alex (Viper007Bond) 6:56 am on October 4, 2009 Permalink | Log in to Reply

        We also have to not forget about those who use TinyMCE and expect to see the image as is. A shortcode would be there as text.

        Perhaps a TinyMCE plugin could AJAX fetch the image (based on ID) and replace the shortcode with the image during editing, then put it back to the shortcode on save. That way it’d still stay a WYSIWYG.

        • aarondcampbell 9:53 pm on October 4, 2009 Permalink | Log in to Reply

          That’s a good point. It’s easy to forget about those using WYSIWYG

    • Barış Ünver 6:33 am on September 26, 2009 Permalink | Log in to Reply

      I’m concerned about the fact that WordPress is getting fatter and fatter each version. Is it really necessary? Couldn’t it be done with a plugin or something?

      Or at least, are we gonna be able to se a lighter (official) version of WordPress? LitePress v2.9.0 maybe?

      • Alex (Viper007Bond) 9:14 pm on September 30, 2009 Permalink | Log in to Reply

        Filesize (aka fat) is not directly related to performance. The image editor for example has literally zero (no joke on the literally) impact on the front page of your site for example as it’s never loaded except in the admin area.

        • Andrew Ozz 12:15 am on October 1, 2009 Permalink | Log in to Reply

          On top of that even in the admin it’s only loaded through AJAX so it doesn’t add any overhead anywhere.

      • aarondcampbell 8:22 pm on October 3, 2009 Permalink | Log in to Reply

        It’s all about the 80-20 rule. I think more than 80% of the people will use this on a regular basis. I probably won’t, but most of my clients will. I’m all for keeping code as lean as possible, but I’m also all for adding this support in. Let’s trim in other areas. Just my 2 cents.

    • Andrew Ozz 1:37 am on September 28, 2009 Permalink | Log in to Reply

      Another solution for the multiple image backup files would be to let the user decide. We can include a checkbox whether to delete the previously edited image (together with all sub-sizes). Since the suffix that is appended to the image filename contains a timestamp, we could do something like “This image was last edited 1 hour ago. If it wasn’t used in a Post since then you can remove the backup files by selecting this checkbox”.

      On the other hand even the cheapest hosting accounts seem to come with a lot of storage so deleting backups would be unnecessary. Also a plugin can add a simple GUI to search the db and return a list of unused backup images that can be deleted. Not sure if something like this would be good for core.

    • Otto 6:07 pm on September 28, 2009 Permalink | Log in to Reply

      I think the key to this problem is the following: “This is necessary to avoid breaking any posts or pages where the image was inserted.”

      Why avoid breaking those posts/pages? If somebody edits an image, then change the image itself. That’s what they will probably expect to happen.

      Having to have them go and reinsert the changed image into the page/post is confusing and unnecessary. We don’t need to save the original. The user uploaded the image, presumably they have the original. An in-place editor should simply overwrite the existing files with the new ones, not try to preserve them.

      • Andrew Ozz 12:30 am on October 1, 2009 Permalink | Log in to Reply

        True, users that know what they’re doing may expect to break old posts when editing an image. However the majority will most likely complain that “the image editor breaks all old posts!”.

        Also we cannot just replace the originally used image with the edited one as images are inserted with “width” and “height” attribs that in most cases will distort the edited image (as Viper007Bond pointed above).

  • Ryan Boren 11:24 pm on March 21, 2008 Permalink
    Tags: media, , ,   

    TinyMCE, media uploader, and plugin updater fixes along with a slew of smaller bug fixes.

     

  • Ryan Boren 6:10 am on March 12, 2008 Permalink
    Tags: media,   

    Media attachments can now be edited directly from within the Media Library thanks to Mike

     

    • Rob 6:35 pm on March 13, 2008 Permalink | Log in to Reply

      Why can’t we add media directly from “Media Library” without having to visit the new post/page screen? We should be able to.

    • Peter Westwood 7:28 pm on March 13, 2008 Permalink | Log in to Reply

      @Rob: The media library like the other sections under “Manage” is where you view existing items not add them this follows the same paradigm as posts/pages/links

  • Ryan Boren 10:39 pm on February 28, 2008 Permalink
    Tags: , media,   

    Media uploader updates from Andy. Dashboard styling changes. Widget back-compat fixes. AJAX interaction improvements when moderating comments. Code cleanup and consolidation. Lot’s of bug-fixing and UI detailing.

     

  • Ryan Boren 6:17 am on February 22, 2008 Permalink
    Tags: media,   

    Big media uploader changes from Andy.

     

  • Ryan Boren 7:10 am on February 19, 2008 Permalink
    Tags: media,   

    Andy landed the first part of the Media Library redesign.

     

    • matheuseduardo 1:37 pm on February 19, 2008 Permalink | Log in to Reply

      after last “svn update blog”, I’m having problem trying write a post..

      Fatal error: Call to undefined function wp_get_current_user() in (..)/blog/wp-includes/user.php on line 87

    • Jorge 8:12 pm on February 19, 2008 Permalink | Log in to Reply

      How can I get involved in development?

    • Kirk M 12:18 am on February 20, 2008 Permalink | Log in to Reply

      Don’t know if it’s related to your problem but I found that the Simple Tags plugin causes that exact error both online and in local Sandbox (XAMPP for Windows–latest version)

    • Kirk M 2:55 am on February 20, 2008 Permalink | Log in to Reply

      I also get that but only when the Simple Tags plugin is activated. The editor functions normally otherwise.

    • Ryan 4:06 am on February 22, 2008 Permalink | Log in to Reply

      This is now fixed. Compatibility with your plugins should be restored.

  • Ryan Boren 10:18 pm on February 16, 2008 Permalink
    Tags: media, ,   

    A bunch of media upload updates from Andy just landed.

     

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel