WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Scott Taylor Toggle Comment Threads | Keyboard Shortcuts

  • Scott Taylor 5:43 pm on March 11, 2014 Permalink | Log in to leave a Comment
    Tags: , , ,   

    Audio/Video 2.0 Update – Media Modal 

    The latest major updates to Audio/Video before Beta were related to editing shortcodes in the medial modal. TinyMCE placeholders for audio and video have been added like so:

    00-placeholders

    When you click the placeholder, the media modal will now be launched. And when you get there, there are some new ways to manage HTML5 playback without writing anything by hand.

    01-audio-details

    Add Multiple Sources

    MediaElement.js provides cross-browser support for many extensions by providing Flash and Silverlight files that will bridge the browser support gap when necessary. Ideally, as many browsers as possible would be using native HTML5 playback. To ensure this, you need to specify multiple versions of your files. Since 3.6, the audio and video shortcodes have supported this by allowing you specify multiple extensions as attributes: mp3="yolo.mp3" ogg="yolo.ogg" wma="yolo.wma", etc.

    A quick and easy way to encode your files is to use FireFogg (works in Firefox only). Here are some instructions for audio and video files:

    HTML5 Audio

    • Click “Make web video”
    • Select a File (your iTunes files on a Mac are in: ~/Music/iTunes/iTunes Media/Music - Pick a tune!)
    • Click “Advanced Options”
    • Uncheck Video, make sure Audio is checked
    • Format: Ogg (Theora/Vorbis)
    • Set quality to 10.0
    • Optionally add metadata
    • Click “Encode” – make sure to change the extension in the file prompt from “.ogv” to “.ogg”

    HTML5 Video

    • Click “Advanced Options”
    • Make sure Audio and Video are both checked
    • Format: choose Ogg (Theora/Vorbis) or WebM (VP8/Vorbis)
    • Optionally add metadata
    • Click “Encode”
    • (Repeat these steps for the format you didn’t select this time)

    There is now a workflow to make adding these extra sources to shortcodes easy:

    02-audio-add-ogg

    Multiple sources are specified now. Make sure to click blue “Update” button to save your shortcode back to the editor.

    03-audio-sources

    Video Workflow

    Here is a video workflow, assuming your shortcode has no attributes and you click it:

    04-video-empty

    Add each video source:

    05-video-add-source

    Optionally add a poster image:

    06-video-sources

    Subtitles

    If you’re feeling CRAZY, add some Subtitles! Here’s a post about them. They’re pretty cool. Probably make sure your web server is serving .vtt files as text/vtt.

    07-webvtt

    Add your subtitles using our easy workflow:

    08-video-add-subtitles

    When you’ve added them, MediaElement knows to support them out of the box:

    09-video-click-subtitles

    Boom. Subtitles while your video plays:

    10-video-show-subtitles

    When you add your subtitles, if will show you a list of “track” elements you have added, you will still need to set your language manually – all will default to English. The idea is that you can add a track element per language. Tracks get stored as the body of your video shortcode.

    tracks

    Testing + Tweaks

    Now comes the time for testing and refining, while fixing esoteric bugs. PLEASE HELP! Put your UI + UX hats on, if you wear that kind of hat.

     
    • Scott Kingsley Clark 6:31 pm on March 11, 2014 Permalink | Log in to Reply

      Is Audio/Video modal stuff able to be integrated into separate fields from TinyMCE yet? Or too early to try testing that?

      • Scott Taylor 6:37 pm on March 11, 2014 Permalink | Log in to Reply

        Great question – yes:
        https://core.trac.wordpress.org/browser/trunk/src/wp-includes/js/tinymce/plugins/wpgallery/plugin.js#L95

        var frame = wp.media.video.edit( data );

        “data” is a shortcode.

        frame.on( 'close', function () {
        	frame.detach();
        } );
        frame.state( 'video-details' ).on( 
        'update replace add-source select-poster-image add-track', 
        function ( selection ) {
        	var shortcode = wp.media.video.shortcode( selection );
        	// shortcode is the updated shortcode, do something with it.
        	frame.detach();
        } );
        frame.open();
        
        • Manny Fleurmond 7:48 pm on March 11, 2014 Permalink | Log in to Reply

          Is there a version of the modal to be used outside of shortcodes and the editor, like how you can use the media select modal in plugins?

          • Scott Taylor 7:53 pm on March 11, 2014 Permalink | Log in to Reply

            I honestly hadn’t thought about other use cases until Scott’s comment. All of the code is in media-editor.js, media-models.js, and media-views.js which get loaded via `wp_enqueue_media()`. If those files + MediaElement are loaded, you can do whatever you want. The admin glue is the “wpgallery” TinyMCE plugin where we have shoved all of the shortcode handlers, playlists too. So, you need your own glue, but see my above comment, it’s pretty easy.

            • Manny Fleurmond 4:21 am on March 17, 2014 Permalink

              Is there a way to use the edit audio/video frames without shortcodes?

            • Scott Taylor 4:25 am on March 17, 2014 Permalink

              wp.media.audio.edit( ‘[ audio ]‘ ).open();

            • Manny Fleurmond 4:39 am on March 17, 2014 Permalink

              So basically, I’d have to encode the data into shortcode before I could even use this modal, then.

            • Scott Taylor 4:47 am on March 17, 2014 Permalink

              wp.media({
              frame: 'audio',
              state: 'audio-details',
              metadata: {DATA_GOES_HERE}
              }).open()

            • Manny Fleurmond 4:58 am on March 17, 2014 Permalink

              Awesome and thank you. 2 more questions, then you can chase me away:

              1. What kind of metadata and how is it formatted? is it just a hash of audio type and url?
              2. Will the same events shown above ( ‘update replace add-source select-poster-image add-track’ ) work with this code?
              3. (wait, didn’t I ask for 3?) what does detach do?

              Thank you and sorry for all the questions. Digging through the code is tricky because I’m still new to backbone so I’m glad that people in the know such as yourself are will to share the knowledge. Can’t wait for documentation.

            • Scott Taylor 5:03 am on March 17, 2014 Permalink

              1. look at “defaults” here: https://core.trac.wordpress.org/browser/trunk/src/wp-includes/js/media-editor.js#L702

              2. Those events are in reaction to what happens in the media modal, they get set up here:
              https://core.trac.wordpress.org/browser/trunk/src/wp-includes/js/tinymce/plugins/wpgallery/plugin.js#L109

              3. Removes the frame from the DOM when the state is to be discarded or the modal is closed.

            • Manny Fleurmond 5:05 am on March 17, 2014 Permalink

              Thank you. I had just played around with the code in the js console and got an output from and update event. Thank you for the starting point. :)

    • Robert Chapin 7:47 pm on March 11, 2014 Permalink | Log in to Reply

      I love that I can upload audio files and have my own player without embedding cross-domain scripts. This is awesome.

    • Gabriel Koen 11:57 pm on March 12, 2014 Permalink | Log in to Reply

      This stuff is awesome!

    • Looimaster 11:09 am on March 18, 2014 Permalink | Log in to Reply

      @Scott Taylor: Would it be possible that you update Codex pages with examples for developers such as `wp.media.audio.edit( ‘[ audio ]‘ ).open();` etc.? It would be beyond awesome to have this documented in detail, with properties, methods, exact parameters, return values, examples etc. I’m not that proficient in JavaScript and it’s hard to find information such as what the actual data (parameters) are for `wp.media()` or for `metadata: {DATA_GOES_HERE}`. If you hadn’t told us that we can do `wp.media.audio.edit( ‘shortcode-here’ ).open();` then few people would be able to get to know that from the source code.

      I think that this page http://codex.wordpress.org/Media_Library could be made like this: http://codex.wordpress.org/Embeds or this: http://codex.wordpress.org/Child_Themes It’s super informative and it’s the only source of information that I’m able to understand quickly and use in plugins and themes.

      PS
      This new media library is an AWESOME step forward. You’re great!

    • Stephanie Leary 3:11 pm on March 23, 2014 Permalink | Log in to Reply

      Where is the relationship between video and subtitle file stored? I’ve played with the latest nightly and I can’t find anything in the posts, postmeta, or options tables that indicates which subtitle file goes with which video. I’d like to be able to query videos with subtitles vs. those without.

  • Scott Taylor 9:04 pm on February 20, 2014 Permalink | Log in to leave a Comment
    Tags: , , playlists,   

    Audio / Video 2.0 Update – Playlists 

    Previously: http://make.wordpress.org/core/2014/01/29/audiovideo-2-0-update/

    It has been a slow and steady burn of commits related to media and necessary for playlists:
    [27059], [27063], [27907], [27100], [27127], [27209], [27212], [27213], [27214], [27215]

    A few items for conversation….

    Thumbnails for Audio and Video

    We have been parsing the ID3 tags in audio and video files on upload since 3.6. ID3 tags, in many cases, contain the binary bits for an image related to the item (album cover, still, etc). On upload, if your theme and the relevant pseudo post type for attachment:audio or attachment:video registered support for thumbnails AND your current theme supported it, we would upload the image bits and attach to the media item as its featured image.

    So basically it was a hidden feature, because it required you to jump through hoops to turn it on.

    add_post_type_support( 'attachment:audio', 'thumbnail' );
    add_post_type_support( 'attachment:video', 'thumbnail' );
    add_theme_support( 'post-thumbnails', array( 'post', 'attachment:audio', 'attachment:video' ) );
    

    On top of that, if you switch themes, and the theme doesn’t support thumbnails for audio or video, the images will no longer appear alongside the media on the Edit Media page. Weird.

    Playlists are best enjoyed with images, videos are best enjoyed with poster images. Soundcloud is doing some awesome things with images in their embeds – see a few on the homepage here: http://highforthis.com. Moral of the story: I think this support should be on by default. Alternately, we could add that code to every default theme’s functions.php, but then what if you switch themes…

    Playlist UI

    As I mentioned previously, the UI for playlists needs to be:
    1) Adaptable
    2) Extensible
    3) Generic

    Translation: it needs to show up in a theme without much drama, inherit the style of the theme, respond the theme’s $content_width, all while allowing you to completely override this behavior. So, what I have is an ultra generic design controlled by settings in the media modal:

    Playlist Settings
    I have tested this in the last 5 default themes:

    Twenty Fourteen

    Screen Shot 2014-02-20 at 3.47.59 PM

    Twenty Thirteen

    Screen Shot 2014-02-20 at 3.48.58 PM

    Twenty Twelve

    Screen Shot 2014-02-20 at 3.49.22 PM

    Twenty Eleven

    Screen Shot 2014-02-20 at 3.50.10 PM

    Twenty Ten

    Screen Shot 2014-02-20 at 3.50.49 PM
    I would like to drop this code in soon, but I wanted to give an opportunity for feedback. All of this can easily be iterated upon once it goes in.

    Documentation of 3.5 Media Code

    This is ongoing – there has been a lot of code churn in the Backbone code, by myself and others, I’ll be picking this back up once that settles down.

     
    • Chris Reynolds 9:16 pm on February 20, 2014 Permalink | Log in to Reply

      I’m soooo excited about this feature.

    • Eric 9:20 pm on February 20, 2014 Permalink | Log in to Reply

      Oh sweet! Please oh please tell me that API support is planned!

    • ScreenfeedFr 9:50 pm on February 20, 2014 Permalink | Log in to Reply

      I’ve been working on similar things recently (bulk import of audio files + multiple playlists among other funny things).

      I came across a problem for the thumbnail (I use the ID3 tag too): detect duplicates. If you upload 10 audio files from the same album, you’ll have 10 identical image attachments too :|

      So far, the only way I have to avoid creating the same image attachment multiple times, is to store the raw data in an array until the bulk import ends, and check for duplicate for each audio file. So it’s pretty limited, but it works, as long as you import all the album files within the same import.

      Did you find a way?

      • Manny Fleurmond 3:57 am on February 21, 2014 Permalink | Log in to Reply

        Maybe store the images on a per album basis?

        • Manuel Schmalstieg 10:12 am on February 21, 2014 Permalink | Log in to Reply

          @Manny : This would be a problem for Nine Inch Nails though, where some albums have different artwork for each track.

        • ScreenfeedFr 12:35 am on February 23, 2014 Permalink | Log in to Reply

          @Manny @Manuel Schmalstieg:
          Indeed, each track could have its own artwork within the same album, that’s why I ran into this duplicate detection :/
          It’s too bad but I think we can’t do anything for that :(

          • Scott Taylor 1:22 pm on February 24, 2014 Permalink | Log in to Reply

            we could store an md5 of the bits as the guid and possibly check before uploading – might tackle that after this initially goes in.

            • ScreenfeedFr 9:21 pm on February 24, 2014 Permalink

              That sounds like a good solution to me :)
              I’m looking forward to see what will happen with themes/plugins that use the guid as url :D (evil laugh)

    • bfintal 1:28 am on February 21, 2014 Permalink | Log in to Reply

      Playlists look geat!

    • Justin Kopepasah 8:38 am on February 21, 2014 Permalink | Log in to Reply

      This feature looks awesome. Great work Scott. Looking forward to diving in.

    • Manuel Schmalstieg 10:36 am on February 21, 2014 Permalink | Log in to Reply

      Looking awesome indeed! Just one little thing: on a site that is run by a band, they should be able to switch off the “by NAME OF THE ARTIST” after each track title. This seems even more important than showing/hiding the track numbers. Especially if it’s an annoyingly long band name, all in uppercase. :)

    • Diego de Oliveira 5:35 am on February 23, 2014 Permalink | Log in to Reply

      I would love to see an easy way to get thumbnails for uploaded audio / video! Working on the CEUX project we have content blocks for media. Getting a poster image for fetched video (at least for youtube and vimeo) is easy, as the providers have an API that allows it, but getting this for self hosted media is another case. And media playlists is a great feature that we didn’t thought about yet. Maybe we’ll need a content block for that!

    • tiaurus 1:45 pm on March 28, 2014 Permalink | Log in to Reply

      What about Cyrillic and other non-latin symbols in audio tags in playlist?

    • sourceforge 10:49 am on April 17, 2014 Permalink | Log in to Reply

      The metadata is extracted from mp3 uploaded, what-if I am using remote url, can we fetch the ID3 tags? or maybe have global and local options for a playlist that can edited manually using shortcode

    • sourceforge 11:05 am on April 17, 2014 Permalink | Log in to Reply

      [26825], sorry

    • jk3us 7:24 pm on April 17, 2014 Permalink | Log in to Reply

      Can you have a playlist of externally hosted audio files?

  • Scott Taylor 8:23 pm on January 29, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Audio/Video 2.0 Update 

    MediaElement

    Upgraded to 2.13.2: [27059]

    Documentation of 3.5 Media code

    #26870 Add (JSDoc)umentation to the Backbone-centric Media files

    This is underway, with several commits already. Slow-and-steady approach. Have started with annotations, gradually adding top-level comments to all class methods. I have been using pseudo-code to map out each file: https://gist.github.com/staylor/10115a0f455e16c6eafd.

    Start with identifying every piece of the tree, then making sure all methods have each piece of the documentation.

    Dashicons

    #26650 Replace media file type icons with Dashicons

    These will replace the “crystal” icon set. For AV2, we are interested in replacing the icons that show up in the media list tables, and using the icons in the placeholders for Audio, Video, Playlist, and Video Playlist shortcodes in TinyMCE content.

    wpautop() changes

    #26864 Consolidate handling of object, audio and video tags in wpautop

    PHP and JS versions of wpautop() need to respect the inner elements of media HTML tags for media: <param>, <embed>, <track>, <source>
    Initial patch – ongoing work from azaozz

    #26628 Use the content of a video shortcode when provided – depends on ^

    Placeholders (TinyMCE views) for Audio / Video shortcodes

    media

    Depends on: #26628

    Chromeless YouTube via ME.js

    #24764 Support mediaelement.js YouTube sources in the video shortcode

    This has a patch: https://core.trac.wordpress.org/attachment/ticket/24764/24764.diff

    I have just been letting it soak in the wild for a day.

    Metadata Regeneration for audio/video

    #26825 Add ability to generate metadata for audio / video files on-demand

    This currently has 2 implementations.

    1. a button on the Edit Media page if your audio or video does not have a row in postmeta for _wp_attachment_metadata (! isset(), not ! empty())
    2. On the fly in wp_prepare_attachment_for_js()

    #1 requires the user to care

    #2 IMO does not scale, as the media modal loads ALL of your media in one fell swoop upon being opened – let’s say you have 300 videos uploaded pre-3.6: there will be no metadata, so you might melt your filesystem by scanning and analyzing 300 files at once.

    This is still in the exploratory phase – would love some UX thinking on this.

    Playlist and Video Playlist shortcodes

    #26631 Add a “playlist” shortcode

    The TinyMCE view code can probably be merged into the wpaudiovideo TinyMCE plugin once #26628 goes in, which has its own dependencies. As I mentioned, Playlists and Video Playlists probably need their own identifying icons.

    I have created a basic UI for playlists that inherits styles from your existing theme. The HTML and CSS is minimal and generic. Here are some screenshots of it in action:

    Twenty Ten

    Screen Shot 2014-01-29 at 3.06.07 PM

    Twenty Eleven

    Screen Shot 2014-01-29 at 3.05.12 PM

    Twenty Twelve

    Screen Shot 2014-01-29 at 3.04.45 PM

    Twenty Thirteen

    Screen Shot 2014-01-29 at 3.05.52 PM

    Twenty Fourteen

    Screen Shot 2014-01-29 at 3.05.31 PM

     
    • @ubernaut 8:31 pm on January 29, 2014 Permalink | Log in to Reply

      lookin’ good!

    • Andrew Nacin 8:31 pm on January 29, 2014 Permalink | Log in to Reply

      Tagging this ‘media’ so it shows up on http://make.wordpress.org/core/components/media/. (Oh hey look at that…)

    • Jose 11:05 am on January 31, 2014 Permalink | Log in to Reply

      That looks so cool. Can’t wait to play with it when I get home.

    • David Lingren 7:59 pm on February 21, 2014 Permalink | Log in to Reply

      First, let me applaud Scott’s efforts in “Documentation of 3.5 Media code”. The comment log in Ticket #26870 shows the complexity of this vital task!

      As a plugin author struggling to add functionality to the Media Manager Modal Window I’ve spent countless hours going over the WP code and the code of other plugins which go to conflicting extremes to extend the WP code. JSDoc comments are much needed and appreciated, but don’t provide much insight to the larger design concepts behind the major parts of the work, such as controller/StateMachine/State/states/workflow and Library/toolbar/menu/router/Region/Selection.

      I’ve seen (very popular) plugins that copy source code from media-views.js, modify it and then replace the WP method altogether by assigning their function to the WP .prototype. There must be a better way…

      Are there any efforts or plans to illuminate the thinking behind Media Manager and/or to make it possible for plugins to cooperate on extending it?

      Thanks again for all your hard work on this difficult and important task!

  • Scott Taylor 6:47 pm on January 13, 2014 Permalink | Log in to leave a Comment
    Tags: , Backbone, , , , Underscore,   

    Audio / Video 2.0 – codename “Disco Fries” 

    Some history:

    I wanted to do a Make post on my wants for Audio / Video in 3.9 to solicit feedback and spark some discussion about what the community wants / needs / doesn’t want / doesn’t need. Adding audio / video in 3.6 was a great first step, but there are some things we can do to continue to modernize Media and give our huge user base even more ways to display and manage their content. We can also make some changes that help developers navigate the new world of MediaElement.js, Backbone, and Underscore.

    First Things First: New Icons

    #26650 Replace media file type icons with Dashicons

    There are some lingering icons in the admin that don’t look as pretty as their MP6ify’d brethren

    Document the “new” Media code introduced in 3.5

    In 3.5, we overhauled Media. @Koop produced some beautiful code, and a LOT of it. Raise your hand if you’ve ever dived in and tried to program against it? Raise you hand if you understand how all of it works? Me neither. As a community, we need to help each other learn what it is and what it does. Documentation will go a long way in getting us all on the same page. Do we have a documentation standard for JS? We need one. While this isn’t the easiest place to start, it is a necessary one. I would be happy to spend time on this, as I have spent many hours recently reading the code and learning how it works. The main files: media-editor.js, media-views.js, media-models.js

    Support subtitles for Video

    #26628 Use the content of a video shortcode when provided.

    This ticket speaks for itself, and already has a patch.

    Generate audio/video metadata on-demand

    #26825 Add ability to generate metadata for audio / video files on-demand

    Add “Playlist” and “Video Playlist” shortcodes

    #26631 Add a “playlist” shortcode

    Adding inline players for audio and video was a great first step. How do I add music to my site? Just upload an MP3 and drop the URL on a line by itself. Done. Or use the audio shortcode. This works most of the time, but can be a little clunky if you want to share an album of your tunes. MediaElement doesn’t “support” playlists out of the box, but MediaElement is JavaScript, and with JavaScript and little UI elbow grease, we can EASILY support playlists.

    My ticket already contains a patch, but is still considered a work in progress. I think the playlist shortcode should produce markup that does the following:

    • Works out of the box with any existing theme: the HTML should be semi-bulletproof. Many of the Player libraries make heavy use of DIVs instead of items that might be overridden easily with CSS: LIs and the like.
    • Gives the developer total control if they want to write their own implementation
    • Exposes enough data to the page so the themer/dev can make their own decision regarding display of album cover, track meta, captions, etc.

    My current implementation drops data onto the page for each playlist inline. A wrapper div “.wp-playlist” will have a script tag in it with type=”application/json”. I do this so that if ‘wp-playlist.js’ is unenqueue’d, the developer still has the data necessary to write their own implementation. The data is reachable in JS like so:

    var data = $.parseJSON( el.find('script').html() );
    

    My current UI for playlist is a basic one, and uses Backbone Views to render the tracklist on load and update the “current” playing track view. There are 2 camps of people when it comes to “JS on the frontend” – one who doesn’t like it (others) and one who says “who cares” (me). One of the reasons I am posting this at the beginning is so we can flesh out issues like this.

    Abstract Gallery logic into “Collection” logic that Galleries, Playlists, etc can use with minimal registration code

    I have already done a first pass at this in the playlist shortcode patch. It goes like this: a “gallery” is really a “collection” of attachments of type “image.” A “playlist” is really a “collection” of attachments of type “audio.” So they should extend or be instances of a “collection”-type class. Currently, the Gallery code has to be dupe’d. By abstracting this code, Gallery, Playlist, Video Playlist, + any other “collection” of media type can be registered minimally.

    Other Ideas

    • In our playlist JS code, emit events that others can hook into – maybe a video playlist is: News clip, ad, news clip, ad, etc. When emitting events before / after an ad, the dev could disable next/prev buttons
    • Make a playlist embeddable on other sites via an iframe or embedded markup
    • Register an endpoint for audio / video that will expose the “embed code” via oEmbed

    Thoughts?

     
    • Joe Dolson 7:00 pm on January 13, 2014 Permalink | Log in to Reply

      Definite thumbs up from the Accessibility team for adding captions support. In addition to that, I’d like to suggest making it possible to enable keyboard accessibility more easily than it is right now. MediaElement.js includes settings which enable this — one is enabled by default, which enables keyboard access to the controls, but without ‘alwaysShowControls’ enabled, it’s not possible for a keyboard dependent user to move focus onto the player, so they can’t take advantage of any of those controls.

      I’d like to see a localization variable so that the MediaElement settings can be adjusted via wp_localize_script, but for keyboard accessibility it may be valuable to make this an option, either via shortcode or settings, so it’s possible for non-programmers to enable keyboard accessibility.

      I’ve got a plug-in, Accessible Video Library that hacks in support for alwaysShowControls by deregistering the default wp-mediaelement script, but that’s not an ideal solution.

      It would also be nice if the caption selector within MediaElementjs could be made keyboard accessible; though that’s probably something that should be handled as a patch to MediaElementjs itself.

      The Add Media Panel, in addition to new documentation, is in desperate need of accessibility work. See #23560. And several other tickets; there are quite a few accessibility tickets on the Add Media Panel.

    • Aaron Jorbin 7:03 pm on January 13, 2014 Permalink | Log in to Reply

      RE: JavaScript Docs.

      the JSDoc standard is pretty close to the phpdoc standard that we use for PHP and thus it makes the most sense in my eyes. There was a passing IRC conversation between members of the team that did the jshint work and the inline documentation that a future project could focus on improving the documentation of our JS. The media files seem like a great place to prototype this.

      http://usejsdoc.org/ is the standard.

      • Eric Andrew Lewis 8:02 pm on January 13, 2014 Permalink | Log in to Reply

        Yes to inline docs. However, I think we’re going to need an alternate form of documentation completely separate from inline to give an easily understandable overview of how media works.

        • Sam Sidler 8:37 pm on January 13, 2014 Permalink | Log in to Reply

          What did you have in mind?

          The inline docs will soon (ish) be present on developer.wordpress.org, which will help the visibility of them. Do you mean something more like a walkthrough on exactly how it works? I’m trying to think of where the best place for that would be. Definitely on the developer hub, but probably not part of the theme/plugin handbooks.

          • Eric Andrew Lewis 10:24 pm on January 13, 2014 Permalink | Log in to Reply

            Not sure to be honest. I think there are limits to inline documentation. Inline is always so contextual to the code it surrounds; separate documentation can speak of overarching design principles and secondary information that doesn’t pertain to any code block in particular.

            WP-API’s documentation for example is quite verbose, and covers a range of topics including the API’s philosophy, tutorials, schema details, etc. None of this could fit easily into inline documentation.

            Full disclosure: I’ve only used the media library cursorily, and am not even sure what secondary documentation for it might look like, so I may be off-base here.

            • Ryan McCue 1:11 pm on January 16, 2014 Permalink

              This is one of the benefits of the new developer site being WP-based: we can mix in inline docs with full pages. (It’s also one of the reasons WP-Parser is architectured that way.)

          • Gregory Cornelius 6:01 pm on January 15, 2014 Permalink | Log in to Reply

            Documenting the parts of the WordPress Backbone code that form more of a “public” API that is intended to be re-used in plugins with a few examples makes sense.

        • Aaron Jorbin 8:45 pm on January 13, 2014 Permalink | Log in to Reply

          I agree that some good tutorials and foundation docs are important, but I think that inline docs can help move us forward.

    • two7s_clash 7:17 pm on January 13, 2014 Permalink | Log in to Reply

      I wanted to point out that for a few years the flash player did support playlists: https://plugins.trac.wordpress.org/ticket/1869/ See also: http://jamesfishwick.com/3-6-audio-so-what-happens-to-blogs-using-the-old-jetpack-shortcode-for-generating-playlists/ Furthermore, I had a popular plug-in that did many of these things you list here called Jetpack Easy Playlists: http://jamesfishwick.com/software/jetpack-easy-playlists/ It worked on your “gallery” paradigm. The playlist still works if you hack Jetpack’s shortcode module and disable its check. If you want this to work with 3.6 and up, edit this file: /wp-content/plugins/jetpack/modules/shortcodes.php

      Change line 51 to: “if ( version_compare( $wp_version, ’3.9-z′, ‘>=’ ) && stristr( $include, ‘audio.php’ ) )”

    • @ubernaut 7:58 pm on January 13, 2014 Permalink | Log in to Reply

      i think this all sounds awesome.

    • s3w47m88 8:02 pm on January 13, 2014 Permalink | Log in to Reply

      We provide custom Theme WordPress websites to our customers and the primary challenge we face, regarding media, is that customers frequently are embedding video from sources beside the big guys (YouTube, Vimeo, etc…) so they have HTML or something. But that requires them to have access to the HTML (insert blood curdling scream here). What would be a potential solution is a simple widget on the right of Pages/Posts that allows them to paste whatever code they have, then see a rendered version without reloading the page, then the ability to drag that rendered video sample into the Visual Editor.

      As much as I like shortcode, customers still don’t get it for some reason. Anything they hear the word “code” they freak.

      • Sam Sidler 9:16 pm on January 13, 2014 Permalink | Log in to Reply

        What you’re talking about sounds a lot like the CEUX project (currently on hiatus).

      • Scott Taylor 9:18 pm on January 13, 2014 Permalink | Log in to Reply

        the shortcodes get inserted automatically from the Media Library, don’t have to be written by hand – they are just the easiest way to save the most minimal data necessary in the post content without hardcoding markup or URLs

    • Tom Auger 9:31 pm on January 13, 2014 Permalink | Log in to Reply

      Sounds like a pretty wide scope of things. I’m primarily interested in extending the Media Editor, and have prepared a feature-as-plugin to this effect as a proof-of-concept. As I missed the deadline for 3.9, I was planning on waiting until the next round to bring this forward, but if work is being done in media-editor.js and friends, perhaps this is a good time to look at the challenges that the current architecture of the Media Editor presents, and my proposed solutions to it.

      • Manny Fleurmond 4:35 am on January 14, 2014 Permalink | Log in to Reply

        I was planning on tackling the media editor as well, specifically making it more modular and using Backbone. Would love to see what you have so far

        • Tom Auger 3:18 pm on January 14, 2014 Permalink | Log in to Reply

          Okay, well, when I get a few hours, I’ll throw up a post and share the code. I’ve completely modularized the “editor groups” – which are basically the Media Editor’s version of Meta Boxes. It is currently **possible** to extend the media editor without core modifications, but it’s really ugly and involves duplicating some core files. This is one of those cases where it would really benefit from some well-placed hooks.

    • mttktz 2:44 am on January 14, 2014 Permalink | Log in to Reply

      Half of what’s important in WP is making sure that it is easy to create great stuff and publish it on the web.

      The other half is people finding that great stuff. Right now other platforms do a better job of sharing and redistributing great stuff. Better or more sophisticated oembed would probably mean more WP posts that look “right” when someone shares them on another site or tries to link to them.

      That sounds really interesting to me – but I’m not sure what you are thinking about there.

    • David Lingren 3:48 am on January 15, 2014 Permalink | Log in to Reply

      I was very excited to read this post!

      As the author of Media Library Assistant (http://wordpress.org/plugins/media-library-assistant/), I have devoted quite a bit of time and effort to enhance the Media experience in WordPress. One of the frequent comments I get in my support forum is “this should be in core”, and I would be delighted to see any relevant parts of my work get to a wider audience.

      Two of your proposals are of particular interest. First, “Document the “new” Media code introduced in 3.5″. I have had several requests to enhance the Media Manager Modal Window, and I have devoted a frustrating amount of time to understanding the code behind it. One of the best aspects of WordPress is its provision for actions, filters and other extension mechanisms; these are nowhere to be found in the Media Manager code. Consider these support requests I’ve received and responded to:

      Media sorting (http://wordpress.org/support/topic/media-sorting)

      MLA and ACF image upload conflict (http://wordpress.org/support/topic/mla-and-acf-image-upload-conflict)

      category selection when uploading media (http://wordpress.org/support/topic/category-selection-when-uploading-media)

      Hide edit cat and tags in media manager (http://wordpress.org/support/topic/hide-edit-cat-and-tags-in-media-manager)

      Different form field for category selection? (http://wordpress.org/support/topic/different-form-field-for-category-selection)

      Problem with Simplefields (http://wordpress.org/support/topic/problem-with-simplefields)

      filter not showing in modal popup window for image (widget http://wordpress.org/support/topic/filter-not-showing-in-modal-popup-window-for-image-widget)

      I would welcome an opportunity not just to understand, but to improve the Media Manager code.

      Second, you propose to “Abstract Gallery logic into “Collection” logic that Galleries, Playlists, etc. can use with minimal registration code”. This is a great idea, and should be extended to all of the items that can be stored in the “Media” Library, not just image, audio and video items. There are many sites using WordPress to manage large collections of other assets such as PDF documents. Let’s give them some attention as well.

      I look forward to following your progress and finding a way to contribute something to it. Thank you!

    • spacedmonkey 4:31 pm on January 19, 2014 Permalink | Log in to Reply

      With this move away from galleries to collections, (an idea which I really like btw), the gallery code should be rewritten to use walkers. This would make it much much easier to override the markup that galleries output.

    • Gregory Karpinsky 9:16 pm on January 22, 2014 Permalink | Log in to Reply

      Mechanism of inserting video from a YouTube channel: show a list of available videos, and let choose one?

      Can be based on formatting the output of a JSON like this one:
      https://gdata.youtube.com/feeds/api/users/musicinsummer/uploads?max-results=25&alt=json&orderby=published&format=5

      Same can be used to show all recent uploads to a channel.

  • Scott Taylor 4:06 pm on November 12, 2013 Permalink
    Tags:   

    Featured Content: Epilogue 

    If you’ve been following along with 3.8/Twenty Fourteen development, you probably know that Featured Content is being handled by the theme now. It is being moved to the Customizer. This approach is wildly different that what I was doing in the plugin, and I am ok with that. Their approach is lighter weight and might be all a theme needs to display a section of featured posts.

    My original idea after @obenland approached me to work on it was way more complex, and it was something  that might not belong in core. Or it might, but the plugin didn’t make a compelling case – once again, no biggie.

    What did we learn from this?
    Having multiple active developers is a must. 15 people had commit, and our meetings had a healthy share of lurkers, but we only had one person doing development. I became the bottleneck for everything, which was enjoyed by no one.

    I like the idea of using plugin development to drive feature development. For plugins to be successful projects, I think the teams working on them need to be staffed properly. I think our team went into like “oh cool, we’ll all kinda work on it and then it will happen” – wasn’t the case. We could have benefited from more planning and tasking.

    The Future
    If anyone would like to continue working on the plugin, please do. I would prefer to focus on core development instead.

     
    • Lance Willett 5:26 pm on November 12, 2013 Permalink | Log in to Reply

      I look forward to seeing this come back in a future “features-as-plugins” sprint.

      • @ubernaut 5:50 pm on November 12, 2013 Permalink | Log in to Reply

        agreed think that it’s a crucial feature for any content driven site and every theme seems to have it’s own solution, would be good i think to have something more universal.

    • Manny Fleurmond 2:13 pm on November 15, 2013 Permalink | Log in to Reply

      Wouldn’t it have made sense to use widgets to do this?

      • shaunandrews 2:19 pm on November 15, 2013 Permalink | Log in to Reply

        I think so, but all I can think about these days is widgets. I think a “Featured Content” widget would have (and still does) make a lot of sense.

  • Scott Taylor 8:47 pm on October 4, 2013 Permalink
    Tags:   

    Featured Content, 10/4 Update 

    I finally put a bunch of work into the coding of the plugin, and I think it is fairly robust at this point. Whether it makes it into core ( or whether it even should) is up for discussion, but I would like to share what I have.

    First, check out the latest code in trunk here: http://plugins.svn.wordpress.org/wp-featured-content/trunk/

    To guide development, I made the following list of requirements. It should also be easier for people to follow along when we can all agree on an initial set of facts:

    UI

    Wherever possible, existing WP functionality and screens will be used. The user should be able to associate posts with Featured Content theme areas as easy as selecting a category or making a post sticky, but, to be more robust, the user should be able to override certain features of a post when it is displayed as a Featured Item in a theme. Example: different title when featured vs what is displayed for a the full post, different image when in a featured module vs the featured image for the post when displayed in single.php.

    Post Type / Taxonomy

    1. A Featured Item uses the featured_item post type
    2. A featured_item belongs to a Featured Area
    3. Each Featured Area is a term in the featured_area taxonomy
    4. Post types can opt in to featured content by adding featured_area taxonomy support
    5. Themes can opt-in by supporting  ‘featured-content’  (the plugin currently brute-forces it)

    Creating / Deleting

    1. Add a post with featured area(s), make sure featured item(s) are created
    2. Trash the post, delete permanently, make sure featured item(s) are deleted
    3. Featured item should not have a title when created, it should inherit from the parent post when empty – view in list tables to verify
    4. If a featured item’s title is edited, it should show that in the list table, unless it is empty
    5. Add a post with a featured area, item is created. Edit post to belong to a featured area, 2nd featured item should be created.
    6. Delete one of the featured items, the other should remain, the post should be linked to only one featured area.

    Transitioning Post Status

    1. Add a post in draft status, make sure featured item is in draft status
    2. Move a post in draft to publish, make sure featured item is moved as well
    3. If a post was created with 2 featured items and one is trashed: if the term is re-linked to the post, the item in the trash should be untrashed, instead of creating a 3rd item

    Trash / Untrash

    1. Trash a post, make sure the featured item(s) are deleted
    2. Untrash a post, make sure the featured item(s) are not created
    3. Trash an existing featured item, make sure post loses tax association
    4. Untrash an existing featured item, make sure post regains tax association
    5. Permanently delete existing featured item, make sure post loses tax association

    Quick Edit

    1. The Taxonomy box for featured items should be present in Quick Edit
    2. All saving logic should fire in AJAX save routine for Quick Edit

    Sorting/Re-ordering

    1. All featured items should be re-orderable via the Re-order items screen
    2. menu_order should be set when items are reordered, only those that change should be sent
    3. When new items are added to a featured area, they should be appended to the end of the list, not the beginning

    Returning Data

    1. By default, featured item contains the post data of the post it belongs to
    2. If any fields have been overridden(post_title, post_excerpt), the post data is a merge of the 2
    3. If the featured item has a featured image, the theme can override by using the property ‘image_id’ to grab the featured image on one of the decorated $posts that is returned when applicable

    Yeah, so that is a mouthful. All of these use-cases are listed in the comments at the top of the plugin file as well. There’s been a lot of discussion about new UI. If someone wants to think way outside of the box and introduce new screens, keep the above in mind.

     
    • Sam Sidler 7:27 pm on October 8, 2013 Permalink | Log in to Reply

      Be sure to tag your posts here with “Feature Content” so those following the tags can keep an eye on your progress. :)

    • Robert Dall 4:39 pm on October 10, 2013 Permalink | Log in to Reply

      Ok Thanks Scott… I will review all of your notes and then rework them in to the UI mockups I have done. When will be the next meeting. So I know to be fully prepared for it…

    • EkoJr 2:21 am on October 11, 2013 Permalink | Log in to Reply

      Thanks for posting this. It really helped fill in some gaps on how to operate it. I’ve been taking a look at Featured Content to see how it works, but tonight I’m going to try and take a deeper look into the code before I start posting questions. Lately, I’ve been working on my own plugin (Advanced Post List) as well.

      However, when I first booted up FC, I started thinking about the practicality, and how it might be overlapped by a theme or plugin. By default, I would have one featured area already setup and ready to go for the user/admin to use. Maybe even give it a similar feel like the Featured Image in WP. Just a couple ideas right off hand, but the Featured Area tab for other post types is laid out nice. The Featured Items menu I imagine still has some work.

      Btw Robert, do you have a repository setup? I wanted to check yours out too.

    • redundans 10:57 am on October 11, 2013 Permalink | Log in to Reply

      Hi Scott, will there be a meeting this monday? We are som devs from sweden that taken big interest in this project (basically because we have a similar plugin that we need to rework http://wordpress.org/plugins/cursorial/). We would really like to help out one way or another.

    • Scott Taylor 7:07 pm on October 11, 2013 Permalink | Log in to Reply

      yes

  • Scott Taylor 7:38 pm on September 24, 2013 Permalink
    Tags: ,   

    Featured Content Update 

    Sorry for no meeting this week, it’s been busy at my j.o.b. In addition to the weekly IRC meeting, we now have a Skype conversation going. Add me as a contact on Skype if you want to join in. My Skype username and Trac username are the same.

    The plugin is in the repo:
    http://plugins.svn.wordpress.org/wp-featured-content/trunk/

    Last week, I made a screen to sort featured items within their respective areas. The logic to save the order when sorting still needs to be hashed out.

    Currently, one person is doing the coding (me). This is not ideal, and I could use help. There have been a bunch of mockups, but I don’t currently have time to build a prototype for all of them. If would like to help with coding, please let me know in the comments.

     
    • notaternet 8:35 pm on September 24, 2013 Permalink | Log in to Reply

      Hello, I would love to help with the coding.
      I have just added you to skype.

    • Robert Dall 8:58 pm on September 24, 2013 Permalink | Log in to Reply

      I am working on the UI today… Regardless of my work scheduled…

    • Robert Dall 1:41 am on September 25, 2013 Permalink | Log in to Reply

      The Feature Content Mockups

      Introduction

      My proposed UI for the Featured content is based on the fact that we have already set a lot of the variables up in the content. We already have a field for: The Content, The Excerpt and the Featured Image all in the post editor. So using this to our advantage we only need to tell the featured content what why want in the plugin.

      What Twenty Fourteen did was to call a featured image, the except, categories and put all of that on the front page. This was a great for this one theme. But what if we wanted the full content or only the title and the excerpt?

      First we need to create a featured content area. This can be done in the featured content main screen (also available in the drop down from the main menu on the left)

      Then we need to tell WordPress which posts it will be part of. We can one of two ways.

      1. We hit the Feature this content check mark box in the post editor window and that then shows a drop down of all featured content area’s available. (Which was suggested by Tammie Lister) We should also have the ability much like the tags and the categories to create a new featured content block from with in the post editor.
      – But this could be problemattic if we want to add multiple posts to a featured content area that have already been created.

      2. We can also select the featured content in bulk from the edit posts screen using the bulk actions. We could then assign which posts or pages we want added to the post format. ( I still need some feedback or am fuzzy on how this would actually work but we should have the ability to bulk add / remove from the edit post screen imho. )

      Ok now we can decide what to call in the featured content area. I have learnt that WordPress development is more about Design Decisions rather then Design Choices but to create different featured content we need to give those choices to the user.

      In this example we have the Bread Feature Content. Which we can then choose what featured content we want via check boxes. (I am still looking for a better word then everything)

      • If people wanted to add only a title and the featured image that is available to them. If they want the title and the content area also available.

      • I haven’t added tags and categories because those don’t exsist for pages in my example. But they could easly be shown for posts.

      • If we want add a description like we do for categories / tags that would be an easy add on.

      • Like the WordPress menus / widgets we just drag and drop what post we want in what order.

      • A short code would then be created and put into any page or post you desired (Although I am not sold on the short code solution I don’t know how we would implement different featured content blocks)

    • Scott Taylor 5:05 pm on September 25, 2013 Permalink | Log in to Reply

      Your mockup completely ignores the overrides, which we have discussed ad nauseum, and was in the first iteration of the plugin.

      • Robert Dall 5:51 pm on September 25, 2013 Permalink | Log in to Reply

        Hi Scott

        A little confusion on my part here. In the last meeting you told us to download the latest version of the plugin and install it and get familiar with it. I did that. There is no reference to the overrides that you spoke of already in the plugin. I made some mockups on integration of how I though the latest version of plugin would integrate best into the WordPress core.

        I also couldn’t find reference to the word overrides in the #WordPress-core-plugins or the channel.

      • Robert Dall 6:23 pm on September 25, 2013 Permalink | Log in to Reply

        I wasn’t able to accomplish the interaction of the “overrides” you speak of in the plugin.

        All I get is:

        This is meta box to display fields, etc about the featured post that does exist.

        I can edit my mockups… But with out seeing this functionally it would be a guess on my part as to how it operates…

    • OpenSource Technologies 10:04 am on October 15, 2013 Permalink | Log in to Reply

      When we the next Skype meeting and how to join that?

  • Scott Taylor 4:48 pm on August 19, 2013 Permalink
    Tags: ,   

    Featured Content: Getting Started 

    Ahead of our first official office hours, here is an overview of what I would like to discuss:

    What is Featured Content?

    Obenland discussed the high-level concept here: https://gist.github.com/obenland/3010432c8edcfcbf95a9

    To me, Featured Content is a flexible way to show one or many posts in one or many places in your theme. A blog might have 1 featured post area that will support 1-4 posts, as an example. A more complex site using WP as a CMS might program its homepage using many “featured areas” that contain varying numbers of post-like entities.

    Featured Content, in the end, is just a way to return posts chosen by a content producer. The way in which featured content is selected should be intuitive, easy to manage, and use existing WP technology/terminology whenever possible. A featured post-like thing should an entity that points at a canonical post, while having the ability to override any of the parent post’s attributes on display. Example: I should be able to use a different title and image for a post that is featured when it is rendered in a featured area.

    I should also be able to schedule featured items, much like I can schedule a post.

    How are we going to implement it?

    Here are my ideas:

    I think we can get a lot of immediate mileage using a custom taxonomy, working name: “Featured Area” and a custom post type, working name: “Featured Item”. By default, a function like `wp_get_featured_content()` can return all featured posts. Passing a parameter can return posts matching that featured area slug that are published – `wp_get_featured_content( ‘mini-header’ )`. A custom taxonomy can be registered to post and featured_item. Themes can register the taxonomy for more post_types as necessary.

    The plugin, in its current form, implements all of the above: http://wordpress.org/plugins/wp-featured-content/

    Things to consider:

    • How do we always keep the post and its featured_item brethren in sync?
    • Do featured_items and posts always share the same post_status? Should they be independent?
    • How do themes opt in to multiple featured areas if the terms have not be created for the featured_area taxonomy?
    • What are alternate ways to implement the above?
     
    • George Stephanis 4:56 pm on August 19, 2013 Permalink | Log in to Reply

      This may be a bit out of scope, but I would like to also consider a wp_get_featured_content( array( 'post_id' => 123 ) ) contrasted with that may wp_get_featured_content( array( 'location' => 'mini-header' ) ) — that could be used to fetch related posts or the like?

      Just have it accept an $args array, rather than a string, so it’s more extensible for plugins to offer new ways to use.

    • shaunandrews 4:59 pm on August 19, 2013 Permalink | Log in to Reply

      I haven’t been following to closely, so please excuse my ignorance, but what if featured content was just a widget (or content block) that you could place into any sidebar area, post, or page?

      A blog might have 1 featured post area that will support 1-4 posts, as an example. A more complex site using WP as a CMS might program its homepage using many “featured areas” that contain varying numbers of post-like entities.

      This sounds very similar to widgets and sidebars…

      With the rethinking of widgets and post-formats-as-blocks, there’s been chatter about combining the two concepts. Widgets would become content blocks, which could then be dropped into a post, page, or widget area. There could be a “featured content” block (né widget) that allows you to pick posts to feature. You could place this block into a “content area” (né “widget area”), post, or page.

      • paaljoachim 9:08 pm on August 24, 2013 Permalink | Log in to Reply

        + 1. Creating consistency is very important. I would suggest merging Featured Content into CEUX. As featured content would be a natural content block one of many that can be added into CEUX. As Content Blocks gets going more and more blocks will naturally also be added.

        Featured Content to me would be like using the short code that I am using through the themify.me shortcode panel. A panel for which categories to show, how many posts to display, order, list/thumb/4-grid/etc. Below is a screenshot from the Themify Page Builder:
        http://easywebdesigntutorials.com/wp-content/uploads/List-Post-Themify-Builder.jpg

        What other good options exist today can we learn from?
        Any good plugins to show features categories/content?

    • Manuel Schmalstieg 5:01 pm on August 19, 2013 Permalink | Log in to Reply

      Here are my 2 cents, from my experience implementing custom themes for various clients. A “featured post” functionality is something i’m using all the time. What I use for that is generally a custom Taxonomy, which holds all the “display settings” that are needed for a site.

      Using a regular Category is generally bad, because it blurs the role of the “visible categories” (visible on the frontend, and in URLs), which for clarity shouldn’t be mixed with “settings” categories, of which the “featured item” is a perfect example. So a custom “Settings” taxonomy is what I consider the cleanest and most logical way.

      Using a Custom Post Type is a bad idea, in my experience, as you cannot easily switch a regular post into another CPT. Imagine that you wrote a post with title, content, image attachments, categories and tags – then you decide this should be a featured item. You would have to copy everything over to the “Custom Post Type”. Bad user experience…

      @ Shaun Andrews: indeed, if we had a “Archive of any Taxonomy widget”, we could use a widget area, and define “last X posts of with Taxonomy:Display Settings and Term:Featured Item…

      • Chip Bennett 5:15 pm on August 19, 2013 Permalink | Log in to Reply

        I think combining custom post meta data with a new “Featured Content” taxonomy is all that’s needed here, and would be quite powerful. The post meta data designates the post as “featured”, and the taxonomy associates the post with other related posts, allowing for multiple groupings of “featured” content. WP_Query calls (with appropriate post meta and taxonomy parameters) in the template handle the rest.

    • Chip Bennett 5:02 pm on August 19, 2013 Permalink | Log in to Reply

      I think creating a CPT is probably too heavy for “featured” content. The status of being “featured” is independent of content type, and as such would be better suited either as a custom taxonomy – or, perhaps better yet: as custom post meta data.

      Using custom post meta data allows any content type – posts, pages, or any custom post types – to be designated as “featured”, and to be queried/displayed accordingly.

      • Manuel Schmalstieg 5:04 pm on August 19, 2013 Permalink | Log in to Reply

        Using custom post meta data allows any content type – posts, pages, or any custom post types – to be designated as “featured”, and to be queried/displayed accordingly.

        Full agreement, as per my comment above.

      • Rohit Tripathi 5:46 pm on August 19, 2013 Permalink | Log in to Reply

        I totally Agree. Using CPT is not feasible at all. Custom post meta data does make a lot of sense. That would be the right way to proceed.

    • Chip Bennett 5:08 pm on August 19, 2013 Permalink | Log in to Reply

      Pet peeve alert:

      …A more complex site using WP as a CMS…

      WordPress is a CMS, and is always used “as a CMS”.

      Pet peeve/rant aside: The front-page.php template file has been around for a long time now, meaning that it is simple for any Theme to designate a custom site front page template. The normal use-case for such a template is “featured” content, so I’m all in favor of standardizing on how content is designated as “featured”.

    • Jonathan Desrosiers 5:19 pm on August 19, 2013 Permalink | Log in to Reply

      I created a quick solution for this (http://wordpress.org/plugins/post-type-spotlight/) because it comes up frequently on our projects. Our plugin adds a check box for content editors to designate something as featured.

      I like the placement, and I think that could work well with the scheduling aspect of featuring, because it could function similar to the Publish & Visibility fields.

      Would there be any disadvantages to assigning it to a specific featured area? Instead of using an area, it could be simply featured, or not featured, and wp_get_featured_content() could accept other parameters, such as which categories/custom taxonomy terms it should also have, or what publish dates, etc..

    • Weston Ruter 5:41 pm on August 19, 2013 Permalink | Log in to Reply

      It seems a key feature to include with these featured content areas is the ordering of posts within them. Consider a news site that has homepage sections for different news categories (Local, National, Sports, Entertainment, etc). Editors need to have control over the ordering of the posts that appear in these featured content areas. Hacking the publish date to ensure proper ordering is not an option, as the same post may appear in a different order in other featured content areas.

      • Chip Bennett 5:43 pm on August 19, 2013 Permalink | Log in to Reply

        That can be custom post meta data, also: “Featured Content Sort Order”

        • Fab1en 7:19 am on August 20, 2013 Permalink | Log in to Reply

          No: the custom post meta data can only be present once : it is not linked to the area. What if my post must appear first in Local category and second in Sports one ?

      • Manuel Schmalstieg 12:44 pm on August 20, 2013 Permalink | Log in to Reply

        Oh, if we could come up with a good solution for “custom-ordering” things, that would be amazing (and would be useful beyond the scope of featured content)! If we would apply the taxonomy logic to featured content, could we imagine that we give to some taxonomies “support for custom-ordering”? And provide a new interface, where the content of each taxonomy term could be ordered by drag-and-drop?

        My typical use case would be: a “Series of posts” or “Related content” custom taxonomy, which gets used by the theme to display “other articles in this series”. Each term then becomes a group of related content (or “featured content”). If that term/group could be ordered, it would be CMS heaven…

    • Chris Olbekson 5:47 pm on August 19, 2013 Permalink | Log in to Reply

      Sorting by postmeta requires a meta_query and I think we can all agree that this is not ideal. I think the term_order column would be great here. See my comments on http://core.trac.wordpress.org/ticket/9547#comment:26

      • Chip Bennett 5:59 pm on August 19, 2013 Permalink | Log in to Reply

        I don’t think there’s anything inherently “not ideal” about using a meta_query, but I certainly agree that term_order would be a better solution all around.

        • Scott Taylor 6:13 pm on August 19, 2013 Permalink | Log in to Reply

          meta_query falls apart at scale

          • Chip Bennett 6:17 pm on August 19, 2013 Permalink | Log in to Reply

            How much scale is needed for “featured” content? Having even 10 “featured” posts would probably be near the edge case.

            As for scale: if I’m understanding the concept properly, the idea is to mimic custom nav menus, and have a CPT that identifies an existing post/page/whatever, so there will be a one-to-one relationship between “featured” CPT and existing content. The CPT is queried, and then each associated post must then be queried from within that query, in order to display post data?

            That seems like a far bigger scale/performance issue than using post meta.

            Alternately: users will have literally have to duplicate content in order to designate a post/page/whatever as “featured” – and I would hope that idea is a non-starter?

            • Zack Tollman 6:19 pm on August 19, 2013 Permalink

              Alternately: users will have literally have to duplicate content in order to designate a post/page/whatever as “featured” – and I would hope that idea is a non-starter?

              I think a better term than “duplicate” is “fork”. It copies the content to the post featured content type. It can then be changed without ever re-syncing the content.

            • Scott Taylor 6:22 pm on August 19, 2013 Permalink

              There is no duped content – the featured_item has the post as post_parent/foreign id. That’s normalized. The only content that is even populated is overrides. “Featured” is really content that is “designated” to an area. The use-case is more for programming a homepage, or ad areas. That won’t be the default use case. But if all we care about is a flag, why not stay with stickies or a category?

            • Chip Bennett 6:29 pm on August 19, 2013 Permalink

              I’m guessing that the most common use-cases will be front-page sliders, and single-post/page feature boxes.

              In any case, the biggest win here is standardizing the method of designating content as “featured”, so that such designation is portable among Themes. Using “stickies” is common, and works, but is limited. Having an actual “featured content” taxonomy would allow for far more flexibility, while retaining standard conventions.

          • Chip Bennett 6:26 pm on August 19, 2013 Permalink | Log in to Reply

            Looking at the referenced Plugin, running two queries is exactly what’s being done:

            $args = array(
            	'fields' => 'id=>parent',
            	'post_type' => WP_Featured_Content::POST_TYPE,
            	'orderby' => 'menu_order'
            );
            
            if ( ! empty( $term->term_taxonomy_id ) ) {
            	$args['tax_query'] = array(
            		array(
            			'taxonomy' => $term->taxonomy,
            			'field' => 'term_taxonomy_id',
            			'terms' => $term->term_taxonomy_id
            		)
            	);
            }
            			
            $query = new WP_Query( $args );
            
            if ( empty( $query->posts ) )
            	return array();
            
            return get_posts( array( 
            	'post__in' => wp_list_pluck( $query->posts, 'post_parent' ), 
            	'post_type' => 'any',
            	'orderby' => 'post__in'
            ) );
            

            The contention is that this is faster/more scalable than a single meta_query?

    • swissspidy 5:51 pm on August 19, 2013 Permalink | Log in to Reply

      Just as Helen noted on Trac, querying for post metadata would be too slow: http://core.trac.wordpress.org/ticket/24857#comment:17

      I think CPT + taxonomy is fine and allows for better flexibility e.g. (multiple) custom featured items for a post.

      • Scott Taylor 5:54 pm on August 19, 2013 Permalink | Log in to Reply

        that’s the main point – a post should be able to be featured in multiple featured areas, with different display data in each, like a different title/image per area

      • Chip Bennett 5:58 pm on August 19, 2013 Permalink | Log in to Reply

        Using a CPT means that one bit of content must be both its original content type (e.g. “post”), and also a second content type (e.g. “featured”). That means that content is inherently duplicated. I don’t get how that is in any way ideal.

        • Helen Hou-Sandi 6:01 pm on August 19, 2013 Permalink | Log in to Reply

          Given that this is exactly how nav menus work (CPT + taxonomy), this seems like a non-argument.

          • Chip Bennett 6:04 pm on August 19, 2013 Permalink | Log in to Reply

            Except that nav menus aren’t a separate type of content; they are a link to content. Featured content is actual content, that already exists as an appropriate content type. “Featured” is merely a designation that describes that content, and correlates that content to other content. Thus, post meta and/or taxonomy is the correctly analogous data type.

        • Zack Tollman 6:17 pm on August 19, 2013 Permalink | Log in to Reply

          I think that the “duplication” is a good thing. Once the content is “featured”, it becomes a different type of content. It then takes on different properties. It is reasonable to think that when content is featured, it takes on a different title, featured image, post content, etc. “Forking” this from the original post makes sense in that we can use the CPT API to manage all of that content. Moving this content into post meta fundamentally changes how we would work with the pieces of content associated with a post. For instance, if we change a title of a post when it is featured and save it as post meta, do we run the “get_the_title” filter on it when retrieving it? I think it makes sense to use the API that is developed for the purpose of interacting with post content and using a new CPT for this purpose makes sense.

          • @ubernaut 3:41 pm on August 20, 2013 Permalink | Log in to Reply

            i think the main issue here is that you end up with a bunch of old no longer featured CPTs and expiration feature for these would resolve that issue imo.

      • Chip Bennett 6:01 pm on August 19, 2013 Permalink | Log in to Reply

        Also, regarding query speed: improve the query if/where need be – and that speed discussion compares taxonomies to post meta, and does not address CPTs particularly.

    • Taylor Dewey 6:35 pm on August 19, 2013 Permalink | Log in to Reply

      Here is an initial round of mockups based almost entirely on a featured item solution that we built for Global News (http://vip.wordpress.com/2013/04/25/global-news-qa/). I took out some of the UI that was more specific to them.

      The architecture we build uses a CPT + CTT. Featured areas are a hierarchical taxonomy. Featured Items are a custom post type generally derived from, and linked to original content. Curating a featured item is done from a separate admin screen (I’d love to see a way to do this from the content itself, too). Each item is sortable within it’s featured area. Adding a new curated item is a three step process that takes place in a modal.

      http://cl.ly/3W3r190k2z1i

    • karmatosed 8:01 pm on August 19, 2013 Permalink | Log in to Reply

      I’ve gone with the easiest option for my first batch of sketch mockups. These show just a single checkbox option. I then explored some potential placing for an editor/allocator/collection (*needs funky name) interface.

      I will be back with a second round of wireframes but wanted to get these out as the easy end of things.

    • karmatosed 9:57 pm on August 19, 2013 Permalink | Log in to Reply

      I have explored some potential allocation screens. I don’t feel either are there yet but worth sharing the experiments.

      The first is the simplest. This can have a theme defined image to allow for users to at a glance understand what areas are featured. To the side are the featured areas and you click into each to see the posts assigned. I’m not sold we should move from the edit post screen assigning I explored earlier but allowing myself to explore.

      The second I like a bit better but still would like to see how more of this could be done in the post edit screen / single post (that’s going to be my next experiment). This has the ability to add or take away so we could even just strip back to the short code. This nods to your work @taylorde so thank you.

      Neither covers fully everything discussed but I’m still playing.

      • karmatosed 5:10 pm on August 20, 2013 Permalink | Log in to Reply

        Building on from the last wireframe, I have explored what collections could be like. This focuses on collections you then assign to content areas for featuring.

    • paaljoachim 9:09 am on August 20, 2013 Permalink | Log in to Reply

      What about adjusting the Create/edit Category to look similar to make a new page/post? To keep the consistency of the overall design method? This way the user can easily create a new category and create a design for it at the same time. I am using templates for the pages/posts/categories. Use an existing template and see the visual changes in the layout area. Modify and save as a new template to be used in other places.
      http://easywebdesigntutorials.com/wordpress/wordpress-mockups/

      I do agree that creating a listing through a category page or regular page of specific posts within a specific category can also be done with a widget/element/content block.

    • karmatosed 10:57 am on August 20, 2013 Permalink | Log in to Reply

      I continued today and moved onto what would things look like if all done in the post edit screen. I’ve added in the ability to pick a featured image (or have it auto select one) and not just using the featured post image. This probably requires some thought about how but it’s something I know was mentioned in the chat so seeing where it could fit.

    • @ubernaut 3:36 pm on August 20, 2013 Permalink | Log in to Reply

      i put this on the trac ticket yesterday it very rough (some missing bits as well) but illustrates my idea of borrowing the menu ui:

    • karmatosed 4:56 pm on August 20, 2013 Permalink | Log in to Reply

      I had a look for another wireframe at what a box would look like on the single post edit screen. This is a simplified format.

    • Robert Dall 10:59 pm on August 20, 2013 Permalink | Log in to Reply

      One of the reason I wanted to part of this group was the ability to show a bunch of content together. What was once template and query based could now be done in the UI would be a great addition to WordPress.

      After reading most of the posts I have seen any reference to see if the user only wants to use a post excerpt as the featured content.

      Or if they wanted more of a Featured Image, Title, Excerpt. Read more link.

      What if they only want featured content that is only the titles of other posts?

      I have done this via wp_query and template for a number of websites and as it helped people who liked to click on both the header and for people who like to click on the drop down.

      See Annotated Screenshot:

      uprising-breads-featured-content

      See actual page here: http://www.uprisingbreads.com/bread

      Or here is another page

      Couple Questions?

      • Is this the actually direction of this plugin or is it an iteration that is heading off in another direction?

      • Also the order of this content could it be controlled by the actual menu order? Or would have to create the “featured content” and then create the drop down menu of the same order?

      And if I have jumped the gun on these topics my apologies…

    • Scott Taylor 2:14 pm on August 21, 2013 Permalink | Log in to Reply

      We are in an exploratory phase. If something interesting pops up, we may move in a different direction.

    • Matt McLaughlin 4:06 pm on August 21, 2013 Permalink | Log in to Reply

      I have to say that I’m with @shaunandrews in thinking that this should not be a new high level UI concept but rather a canonical implementation of how to use Content Blocks/Widgets to achieve the same goals. The absolute last thing I want for my users is yet more UI concepts to confuse them. A grand unification of all the types of static and dynamic content blocks whether they appear on the front page, a post, page, or in a sidebar is just exactly what the doctor ordered.

      That said, I think there’s a lot that can be done in terms of simplifying the act of choosing and formatting content for highlighting using a really well thought out core Content Block for featured content.

      More musings here: http://mattnamclaughlin.wordpress.com/2013/08/21/featured-content-as-a-widget-or-content-block/

      • Taylor Dewey 6:52 pm on August 23, 2013 Permalink | Log in to Reply

        I agree. In fact, I’ve used my version of a featured item curator as a replacement for the menu system on one of these projects.

        However, it was significantly less flexible than the current implementation. And same with widgets. Making a UI that can manage all of those will require some serious work. However, I’d love to see a UI that can accomodate everything that we need to go this route in the future.

    • magicroundabout 8:21 am on August 29, 2013 Permalink | Log in to Reply

      Hi Everyone,

      I’ve been following some stuff on core but have not contributed before. This conversation caught my eye.

      There’s a couple of requirements that I have for this that hasn’t been mentioned yet:

      • you might want links to things other than single content items. Custom links to external resources, media items, archives of posts
      • different images have been suggested, but you might want to display a different title too. Some of my featured areas have limited space and you might need an alternative title to fit the space.
      • Sometimes these areas need to contain multimedia. So would it be possible to have an option to insert an oembed code?

      I definitely think a menus-like interface with defined areas and drag-and-drop organisation would work better than a meta-box on existing post types, or as a custom post type or taxonomy. For me that’s just not flexible enough. But the ability to be able to choose posts to go in a featured area remains a must.

      Hope that’s useful. I’ll keep an eye on the conversation and try to contribute if I can.

      Thanks

      Ross W

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

    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.

    • Frank 10:46 am on April 10, 2013 Permalink | Log in to Reply

      Yeah, this is cool. And I miss some important points to have this as a useable feature for real blogger’s life: mejs is out of the box not resonsible and this allone makes the joy half at the first glance. Yes, there is a dev’s tip for videos out there, that, if you set the width to “100%” it will work. And it does, indeed! Maybe this width issue of mejs videos should go into core?

      Responsive mejs audio seems to be more complicated. A simple width attribute setting does not work. At this time the width of the audio bar overlaps the standard width of 480 even in modern smartphones.

      Regarding video: the poster attribute of the shortcode is rather important, since it leeds to a screenshot like above, showing this nice preview picture for the video – but it’s not as easy to implement as it looks like. If you take an image from the media library with its predefinded sizes, it is to small or you’ll have an overlapping picture. For me setting the CSS class “mejs-container” to “overflow: hidden;” seems to resolve the issue as a quick hack.

      I think, the feature of having core supported video and audio is great, and it should be delivered in a way, that avoids frustration of users. The poster feature for videos is essential I think, the contra responsive issues should disappear as well.

      Keep up the good work!

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

      Totally wow.

    • Angelo Mandato 7:03 pm on April 10, 2013 Permalink | Log in to Reply

      I see a lot of potential for the post formats. I see many problems though.

      If it is in WP core, it should be capable of both themes and plugins to utilize the functionality. At present the formats are hard coded and there’s no way for themes/plugins to add additional formats. Worse yet, if a theme only implements the audio/ format, it appears to process all 6. (line 203 of wp-admin/functions/post.php). There are no action hooks / filters either.

      The post formats still display even though older themes do not call the function add_theme_support( ‘post-formats’, …). Plus if a theme only specifies 1-2 formats, only those specified formats should be available when editing posts. It does not appear to let you add custom formats either, which would be the bee’s knees.

      Who ever is managing (supervisor or committee chair) of the post formats features could contact me, that be great. My email is cio [at] rawvoice dot com.

    • 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?

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