WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: jQuery Toggle Comment Threads | Keyboard Shortcuts

  • Scott Taylor 6:47 pm on January 13, 2014 Permalink | Log in to leave a Comment
    Tags: , Backbone, jQuery, , , 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.

  • Andrew Nacin 6:58 pm on December 17, 2012 Permalink
    Tags: , jQuery   

    The release cycle for WordPress 3.6 isn’t going to start until January, but we can of course start to drop in some early things before then. (This worked out nicely before the start of 3.5.)

    With that in mind, I have added jQuery 1.9 Beta 1 to trunk. It comes with a migration plugin for deprecated/removed features, and this migration plugin issues warnings in the console so we may fix them. Yes, we are likely to ship the migration plugin in 3.6 final; that’s why it exists. But for now, we should aim to fix anything not only outright broken in core, but also any warnings. (There are a lot of them.)

    For more, see the jQuery announcement post and the WordPress core Trac ticket, #22975.

    A side note: If you are using the WordPress Beta Tester plugin and wish to go back to the 3.5 branch, you can do so by changing the update stream setting from “Bleeding edge nightlies” (which is currently 3.6-alpha) to “Point release nightlies” (which is currently 3.5.1-alpha) and then downgrade. Of course, we’re happy to have you testing the 3.6 branch, which will be kept fairly stable throughout its development.

     
    • Eric Mann 2:51 am on December 18, 2012 Permalink | Log in to Reply

      I like the idea of the migration plugin … but I’m hesitant shipping any library that includes “Beta” in its version number. What’s to say parts of the API won’t change by the time 1.9 is finalized? Not to mention the possibility of shipping bugs with our own release…

      • Japh 3:13 am on December 18, 2012 Permalink | Log in to Reply

        Most likely something that’s beta now, will be stable by the time we’re ready to ship it. It makes more sense than going with the current stable and shipping that even after it’s out of date, or switching further through the dev cycle and not taking full advantage of new features.

      • Andrew Nacin 5:06 am on December 18, 2012 Permalink | Log in to Reply

        Sorry, I should have mentioned that jQuery 1.9 is due out in January, well before 3.6 would even be in beta.

        We strive to always ship the latest of packaged external libraries. By being good citizens and dropping pre-release packages into our own trunk, we contribute greatly to the upstream project while also ensuring there *won’t* be bugs with our own release.

    • moebiusmania 9:05 pm on December 27, 2012 Permalink | Log in to Reply

      hi, there is any possibilities of having the $ alias for jQuery by default in 3.6?

      • Andrew Nacin 3:44 pm on January 10, 2013 Permalink | Log in to Reply

        No, likely not. jQuery.noConflict() — used for historical reasons because of potential conflicts with other libraries, primarily Prototype — also happens to enforce better code. You can still use $ in code, you just have to be smarter about it:

        jQuery(document).ready( function($) {
           // You can use $ in here
        });
        

        Or:

        (function($) {
           // You can use $ in here
        })(jQuery);
        
  • Ryan Boren 3:16 am on May 7, 2011 Permalink
    Tags: 32compat, jQuery   

    Just a heads up. WP trunk uses jQuery 1.5.2. 1.5.2 no longer allows selectors of the form [property=value]. These selectors now require quotes: [property="value"]. Unquoted values will result in “uncaught exception: Syntax error, unrecognized expression: [property=value]“. Check your plugins against 1.5.2.

     
  • Andrew Nacin 10:07 pm on February 10, 2011 Permalink
    Tags: jQuery   

    If your menus or widgets screens broke… 

    WordPress 3.0.5 was released at the same time as jQuery 1.5. Unfortunately, 1.5 has some backwards incompatible changes that appear to break a number of areas in the admin. The timing is awkward and it looks like it was us. It wasn’t.

    There’s nothing we can do about this even for WordPress 3.1, which is freezing at jQuery 1.4.4.

    If your theme deregisters jQuery and re-registers jQuery 1.5, then you’ll want to make sure that this change only applies for the frontend, i.e. ! is_admin(). (Or use the wp_enqueue_scripts hook, which only fires for the theme-side.) This might not be obvious — if you’re enqueueing the latest jQuery from, say, Google’s CDN, you’ll be getting 1.5 suddenly, and things will break.

    Someone should put together a quick plugin that restores and enforces the bundled jQuery in the admin. I’ll do it later tonight if no one else does.

    Reference: #16508 and numerous support forum threads.

     
    • Milan Dinić 10:20 pm on February 10, 2011 Permalink | Log in to Reply

      This is why I’m always discouraging usage of wp_deregister_script and wp_register_script for jQuery from Google and instead encourage usage of Use Google Libraries plugin or its class which is the only right way to load jQuery and other libraries from Google.

      • Andrew Nacin 10:22 pm on February 10, 2011 Permalink | Log in to Reply

        I think that plugin would cause the same problem. It looks like it’s still replacing the script in the admin.

        • Milan Dinić 10:38 pm on February 10, 2011 Permalink | Log in to Reply

          Yes, it is replacing script in admin but it replaces with the same version as used in WordPress. See here.

          It also check if is_ssl, strips ?ver= from URL, adds jquery.noconflict, and loads development version if define('SCRIPT_DEBUG', false).

          I always promise to write a post on this subject but forget to do it. Will do that soon.

        • Otto 11:10 pm on February 10, 2011 Permalink | Log in to Reply

          Correct, the Use Google Libraries plugin correctly handles version numbering. Specifically, it causes both admin and front to use http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js (with 3.1RC4). This prevents the breakage.

        • Jason Penney 4:52 pm on February 14, 2011 Permalink | Log in to Reply

          The majority of the work on Use Google Libraries has been to make sure that it will do-the-right-thing and will not cause these kinds of issues (also, as demetris points out below, there’s a caching benefit to using the full version with Google’s servers). I do get a lot of requests to have it load the latest versions, but I’ve resisted adding it even as an option since I’m worried about it having unintended side-effects such as this.

          If there are any areas like this where you feel it needs improvement I’d be happy to know.

        • Andrew Nacin 4:57 pm on February 14, 2011 Permalink | Log in to Reply

          Yep, I stand corrected — it looks like great work. :-)

    • demetris 11:08 pm on February 10, 2011 Permalink | Log in to Reply

      Specifying only the major version is not a good idea in any case (or at least in any scenarios I can imagine). Not only things break, but you also get a very short cache period: 1 hour.

      Specifying major + minor version (e.g.: 1.5) avoids API incompatibilities, but you only get 1 hour of caching again.

      Specifying major + minor + maintenance (e.g.: 1.5.0) is the best option: In addition to avoiding incompatibilities, it also gets you one full year of caching.

      • demetris 11:09 pm on February 10, 2011 Permalink | Log in to Reply

        I failed to mention: The above are true for the Google CDN. I don’t know how other public CDNs, like Microsoft’s, handle caching.

    • hakre 11:43 pm on February 10, 2011 Permalink | Log in to Reply

      Re-freeze on 1.5 as a shortcut for WP 3.1. Should be a matter of hours.

    • garyc40 12:17 pm on February 12, 2011 Permalink | Log in to Reply

      From what I’ve seen so far, it seems like there’s some incompatibility between jQuery UI and jQuery 1.5. So there’s probably nothing WordPress can do right now until jQuery UI gets updated.

    • Ashley 12:34 pm on February 15, 2011 Permalink | Log in to Reply

      I have upgraded to 3.0.5 and I am loading Jquery 1.4.4. (via google api) and only on the (! is_admin) frontend.

      I can’t order/reorder my wp nav (drag and drop) BUT have noticed the WP menu (left) open close functionality doent work on the menu order page but works elsewhere?
      There seems to be something with this pages functionality, not google as I am loading whichever WP uses for Jquery backend by default?

      I have also deactivated ALL plugins which made no difference either?

      I also don’t know how to downgrade back to 3.0.4 – if anyone has this data and can post a link – thanks in advance. Though I would be greatful if someone can shed some light on this as it doen’t make sense.

      • Andrew Nacin 12:37 pm on February 15, 2011 Permalink | Log in to Reply

        Hi Ashley,
        The proper place for support is http://wordpress.org/support/ — to answer your question, downgrading means undoing some security enhancements (which is bad). It also won’t solve your problem. You probably have an unrelated JavaScript conflict. (Or try a force-refresh of your browser, to clear the cache.)

        Anyway, check out the support forums, they’ll help you there.

        • Ashley 1:14 pm on February 15, 2011 Permalink | Log in to Reply

          Thanks Andrew,

          Good advice, I reset all Caches, rebooted server etc. logged out, did all the same again and eh voila, draggable menus back!

          Kee p up the great work, steller product

    • Gustavo Bordoni 11:40 pm on February 26, 2011 Permalink | Log in to Reply

      Hi Andrew,

      I have a problem with the jQuery UI Tabs, and it throws the following error:

      “uncaught exception: jQuery UI Tabs: Mismatching fragment identifier.”

      I can’t solve this problem.

      Thanks in Advance.

      • Ryan Boren 12:46 am on February 27, 2011 Permalink | Log in to Reply

        Read more about the fragment identifier exception here. Recent versions of ui.tabs are stricter in what they will accept, and your theme/plugin will have to be changed.

  • Ryan Boren 5:59 am on August 9, 2008 Permalink
    Tags: jQuery   

    Updated jQuery UI to 1.5.2.

     
  • Mark Jaquith 12:29 am on June 30, 2008 Permalink
    Tags: auto-suggest, jQuery,   

    Tag auto-suggest now works for more than just the first tag. Before, you had to hit “enter” and send each tag down below if you wanted to use auto-suggest, because once you typed a comma, auto-suggest would stop working. Super-lame. Now it works like you think it should.

     
  • Ryan Boren 7:46 pm on June 27, 2008 Permalink
    Tags: jQuery   

    Updated to jQuery UI 1.5.1

     
  • Ryan Boren 6:34 pm on May 21, 2008 Permalink
    Tags: jQuery   

    Updated jQuery and jQuery UI to the latest from the jQuery trunk.

     
  • Ryan Boren 12:25 am on February 19, 2008 Permalink
    Tags: jQuery,   

    Timestamp editing is now in the post box area and disclosed through a jQuery slide down.

     
  • Ryan Boren 7:16 pm on February 8, 2008 Permalink
    Tags: jQuery   

    Updated trunk to the recently released jQuery 1.2.3

     
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