WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Scott Taylor Toggle Comment Threads | Keyboard Shortcuts

  • Scott Taylor 2:07 am on August 29, 2014 Permalink | Log in to leave a Comment
    Tags:   

    A more powerful ORDER BY in WordPress 4.0 

    orderby is the argument passed to WP_Query to tell it what column to sort on when it is creating the ORDER BY clause for its generated SQL. The default value for orderby is post_date.

    The default sort order for a column in MySQL is ASC (ascending), with smallest values first. For the reverse, DESC is used. You can sort on multiple columns, and each column can have its own sort order.

    The default value for the order argument inside WP_Query is DESC. ~23% of the internet automatically queries posts in reverse chronological order because of this. order can only be one of 2 values: DESC or ASC.

    orderby accepts a string, representing a column on which to sort:

    $q = new WP_Query( array( 'orderby' => 'post_title' ) );
    
    // or an alias
    $q = new WP_Query( array( 'orderby' => 'title' ) );
    

    Both will produce an ORDER BY clause like:

    ORDER BY post_title DESC
    

    orderby will also parse a space-delimited set of columns:

    $q = new WP_Query( array( 'orderby' => 'title author' ) );
    

    Prior to 4.0, there was a problem: the value for order would only be applied to the last value that you passed in that space-delimited list, producing an ORDER BY clause like:

    ORDER BY post_title, post_author DESC
    

    Remember that the default sort order for a column in MySQL is ASC, so queries like that can get weird real fast and produce unexpected/unpredictable results. If no value is passed for order for a column in the generated SQL, the column will be sorted in ASC order. This was not so clear to all developers. #26042 was a joy to debug.

    In 4.0, when you pass a space-delimited set of values, your sole value for order will be applied to all of your values that are parsed for orderby. This was fixed in [28541].

    So that’s pretty good, but it doesn’t allow you granular control over the sort order for each column. The syntax doesn’t allow itself much room for extending.

    Enter [29027].

    In 4.0, you can now pass an array to WP_Query as the value for orderby. The syntax looks like:

    $q = new WP_Query( array( 'orderby' => array( 'title' => 'DESC', 'menu_order' => 'ASC' ) ) );
    

    This allows you to control the generation of the ORDER BY clause with more specificity:

    ORDER BY post_title DESC, menu_order ASC
    

    Pre-4.0, you would have had to use some gnarly filters on the SQL statement or a specific clause. No bueno.

    To see the internals, check out the new protected methods in WP_Query: ->parse_order() and ->parse_orderby.

    Happy WP_Querying!

     
  • Scott Taylor 5:49 pm on June 20, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    like_escape() is Deprecated in WordPress 4.0 

    @miqrogroove has written a blog post on his personal blog explaining why like_escape() has been deprecated in WordPress 4.0. It has been reposted below.

    Plugin authors and website developers who work with WordPress database queries should notice an important change coming in WordPress 4.0.

    The function like_escape() is no longer used in WordPress core code. It is still available as a deprecated function, so it still works in any existing plugins that rely on it. However, a new and different function is available that should be used in all new code.

    Deprecated means that anyone using code that calls like_escape() with WP_DEBUG enabled will see an error message. If WP_DEBUG_LOG is also enabled, the error message will appear in the /wp-content/debug.log file.

    Let’s look at an example of core code where I removed like_escape() and implemented the new function $wpdb->esc_like().

    3.9 Old Style

    $search_orderby_s = like_escape( esc_sql( $q['s'] ) );
    $search_orderby .= "WHEN $wpdb->posts.post_title LIKE '%{$search_orderby_s}%' THEN 1 ";
    

    What did this do? It was an old snippet from /wp-includes/query.php that set up a search for post titles. The input $q['s'] was escaped using two functions before it was added to the post_title LIKE expression. Now let’s see how I replaced that snippet in the next version.

    4.0 New Style

    $like = '%' . $wpdb->esc_like( $q['s'] ) . '%';
    $search_orderby .= $wpdb->prepare( "WHEN $wpdb->posts.post_title LIKE %s THEN 1 ", $like );
    

    There are two important differences to notice.

    • I changed the like_escape() call to $wpdb->esc_like().
    • I changed the esc_sql() call to $wpdb->prepare().

    The second change is important because esc_sql() is not secure if it is called before, or inside, the call to the new function $wpdb->esc_like(). By relying on the preferred style of the function prepare(), I can easily see that each instance of $wpdb->esc_like() will run first instead of last.

    4.0 Alternative Style

    Here is something that still works, but I avoided using it. Notice the old query is unchanged. It is critically important to call the two escaping functions in the correct order when using $wpdb->esc_like().

    $search_orderby_s = esc_sql( $wpdb->esc_like( $q['s'] ) ); // This is the correct order.
    $search_orderby .= "WHEN $wpdb->posts.post_title LIKE '%{$search_orderby_s}%' THEN 1 ";
    

    How Should I Get My Code Ready for 4.0?

    The nice thing about deprecated functions is that you can still use them and they don’t change. Your existing code should work fine.

    When you write new code, remember that using $wpdb->esc_like() is not compatible with WordPress 3.9. This should be avoided if you need compatibility with old versions. When you are ready to adopt 4.0 as your minimum version, consider using the new function.

    If you have a specific need for the new function in old versions of WordPress, I suggest copying the new function into your plugin under a different name. This would be the simplest solution, but rarely necessary.

    Why Did like_escape() Change to $wpdb->esc_like()?

    There were several problems with the old function that could not be fixed.

    • Documentation said the function’s output was safe to use in SQL queries. That was not correct.
    • The function’s output was not fully compatible with LIKE expressions in MySQL.
    • The function had been used many different ways in core code, some of which were incompatible with the desired output.
    • Changing the old function instead of creating a new one would have caused many security problems in plugins.
    • The function was related to $wpdb because of its MySQL syntax, which does not work on other databases.

    Is There a Security Problem with like_escape()?

    The old function like_escape() was not intended to be used in any security sensitive context. There are no security problems when it is used correctly.

    With that said, I am concerned that plugin authors frequently confused the old function like_escape() with esc_sql(), which was used for security. The documentation for like_escape() was misleading and very confusing about this point.

    Just remember, like_escape() does not provide any security for your database!

    So What Does $wpdb->esc_like() Do Anyway?

    Whenever user input or other raw data are copied into a WordPress query, the data must be escaped using $wpdb->prepare() or esc_sql(). This prevents certain characters, such as quotes, from getting confused with SQL commands.

    In a LIKE expression, there are additional special characters that are used as wildcards to search for partial matches in the database. Those wildcard characters have to be escaped from the user input so that they are not confused with the wildcards added by the programmer.

    Before adding user input to this type of search query, $wpdb->esc_like() should be called for compatibility, and then $wpdb->prepare() must be called for security, in that order.

    How to Use $wpdb in Functions

    It is very rare to use $wpdb->esc_like() without also running a query. But just in case you want to …

    function my_search( $input ) {
        global $wpdb;
        $escaped = $wpdb->esc_like( $input );
        ...
    }
    

    … remember to reference $wpdb as a global variable.

     
    • Mike Schinkel 6:08 pm on June 20, 2014 Permalink | Log in to Reply

      Nice writeup.

      Note there’s a code type in your “40 Alternate Style”: $wpdb->esc_like( $q['s'] )

    • JasWSInc 6:09 pm on June 20, 2014 Permalink | Log in to Reply

      I hope we will see an `esc_like()` function to serve as a wrapper for this wpdb class member like all the others (i.e. `esc_sql()`, `esc_attr()`, `esc_html()`, etc). Not a big deal to call it through the class instance, but it would be nice to have the function also; i.e. `function esc_like()`

    • Michael Adams (mdawaffe) 8:30 pm on June 25, 2014 Permalink | Log in to Reply

      Nice.

      $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %L", "Something%" ) would be cool.

      • Robert Chapin 11:38 am on July 9, 2014 Permalink | Log in to Reply

        We wouldn’t be able to interpret the % chars in a meaningful way with that syntax. By running $wpdb->esc_like() first, you still have the power to add % chars that are not escaped before preparing the query.

        • Michael Adams (mdawaffe) 9:37 pm on July 14, 2014 Permalink | Log in to Reply

          You’re right. My example was bad. Thanks.

          The following would work:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %L%%", "Something" )

          Which would be the same as:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %s%%", $wpdb->esc_like( "Something" ) )

          Which is the same as:


          $wpdb->prepare( "SELECT * FROM `$wpdb->posts` WHERE `post_title` LIKE %s", $wpdb->esc_like( "Something" ) . "%" )

    • rajlaksh 5:36 pm on August 9, 2014 Permalink | Log in to Reply

      Thanks for This Valuable Post.

      But i found it little difficult so i swift $WPDB to MySqli.

      MySqli easier than $WPDB. :)

  • Scott Taylor 8:46 pm on June 7, 2014 Permalink | Log in to leave a Comment  

    Community Priorities 

    Triaging tickets takes a lot of time and is often thankless work. Testing patches and making sure they are committable is equally as time-consuming. Being a gatekeeper to those tickets going into core is also tough – sure, you can commit anything, but you are also the first person responsible when it breaks or there weren’t unit tests in place (when there should have been).

    As a community, we often have 2 major goals:
    1) Fix everything
    2) Make everything better

    Since we are still in the midst of defining what 4.0 will ultimately be, I would like to ensure that the community once again has a voice as far as “priority” tickets go, outside of dev chat.

    If there is an important ticket that you feel has been neglected, comment below. Seriously. There is always frustration from those who say “my ticket never gets looked at!” – for anyone feeling especially disillusioned, remind us publicly to give you some feedback. This does not mean that every ticket deserves to ultimately go in right away, but let’s talk about it.

    Speaking for myself, I often sit down at the computer and say “my goal today is to commit 100 tickets!” – I usually end up committing 8, over the course of 5 hours. And most of those tickets haunt me for weeks. Everyone is held to a high standard and expected to follow through when they make a decision for everyone else.

    We ALL want the same thing. Let’s work together to get there!

     
    • Robert Dall 8:53 pm on June 7, 2014 Permalink | Log in to Reply

      This has a patch it just needs a review… 
      plugins cannot filter `the_content` for Gallery post format on index views

      https://core.trac.wordpress.org/ticket/25335

      It has been debated whether is it worthy to patch something so “trivial” but if it is still a default theme and bundled with core then I think it is something that should be fixed…

    • Jonathan Brinley 9:00 pm on June 7, 2014 Permalink | Log in to Reply

      Thanks for asking, Scott. It’s hard to get attention to a patch without coming across as a whiny attention seeker. I appreciate having this forum. Without further ado…

      https://core.trac.wordpress.org/ticket/17817 – Fixing filter/action recursion

      Has a patch, has unit tests, has performance tests, has plenty of community feedback, and it fixes a bug that’s lived in core for seven years.

      The ticket itself had a fair amount of feedback for a while, but now that all the concerns have been addressed, it’s gone silent. Is there anything else I can do to help advance this ticket?

    • Niklas 9:31 pm on June 7, 2014 Permalink | Log in to Reply

      I’m unsure whether or not there are tickets on all of these subjects and my trac-fu is not good today… But here are some wishes:

      • The ability to use TinyMCE in widgets.
      • The ability to prevent plugins from breaking when WP auto-updates. I know the fault does not lie with WP, but sometimes plugins break things, and when the break things during auto-update things get worse because you are not there to discover it right away. Some setting to only allow auto-update if all enabled plugins are marked as compatible with the new version would be awesome!
      • Combine/compress CSS/JS files. This one I found a four year old ticket for (https://core.trac.wordpress.org/ticket/11453) but I believe this might be reconsidered now that a CSS preprocessor has been impleneted (https://core.trac.wordpress.org/ticket/22862). What do you say? The code is already there to sort JS files correctly according to dependencies.

      • Marius Jensen (Clorith) 5:20 am on June 11, 2014 Permalink | Log in to Reply

        Regarding plugin breakage from automated updates, I don’t see this as something that should be a problem for the default behavior. The default behavior of the updater is to only apply minors which generally mean security and bug fixes for the most recent version.

        I guess this does become a whole other question if you enable automatic major updates, perhaps adding a new configurable option alongside major updates to check compatibility of existing enabled plugins? (this should ONLY apply for manually enabled major updates, I think it’s important to maintain the default behavior of potential security patches etc be handled as they are; “instantly”)

        • Niklas 12:53 pm on June 14, 2014 Permalink | Log in to Reply

          I’ve had a dozen or so things break over the last year and a half on minor updates, there have been three types of error:

          a) It breaks because caching plugins (W3 TC, and WP Super Cache, I’m looking at you… :) ) does not update their cache properly.
          b) A plugin author has created a work-around for a bug that was fixed in the minor update and the two fixes now collide.
          c) The plugin author depended (for some stupid reason) or otherwise made code assumptions on the erroneous behaviour and therefore the update broke the site.

    • @ubernaut 10:04 pm on June 7, 2014 Permalink | Log in to Reply

      heres mine:

      https://core.trac.wordpress.org/ticket/11302

      basically ht issue is that in bulk editing mode there is no way to remove categories which can make for an incredibly arduous manual process of removing the categories one by one. i believe all the ui issues have been resolved at this point and there is also end user interest on this one:

      http://wordpress.org/ideas/topic/deselect-categories-in-bulk-edit

    • Bryan Petty 10:50 pm on June 7, 2014 Permalink | Log in to Reply

      You asked me to list all of my high priority tickets in the IRC channel. Nobody actually cares, but I built a whole report for it. I honestly feel like most of the 600+ tickets here have been terribly neglected:
      https://core.trac.wordpress.org/report/46

      Seriously… This report contains roughly the same number of unreviewed patches now as it did when I wrote the Bug Gardening guide two years ago. There’s patches in here that go for years without any feedback from the core team at all, not even to say that it’s not acceptable, or to even suggest that it could use some improvements. This report should only contain new patches submitted in the last couple weeks. Everything else should have either been rejected (with explanations), or committed.

      I’m not going to sit here and list off all of my open patches that have been neglected (and yes, I do have some). That’s not fair to anyone else that also submitted patches to Trac that isn’t here to speak for themselves. You aren’t asking them, and that’s part of the problem itself. Just the mere fact that a patch is uploaded and submitted to Trac *is* the indication that it’s important to someone in the community, and that the contributor thinks it’s important enough to donate their work to the entire community.

      • solarissmoke 12:44 pm on June 8, 2014 Permalink | Log in to Reply

        +1

        Come here to say exactly this! There are tickets in that report which (at the time) had working patches, and were even tagged for commit, but were ignored. Some of them are now 7 or 8 years old.

        Would be very, very happy to see a more systematic trac process, so that each ticket is funnelled through a review process within a specified timeframe (during which it is either accepted and actively wrangled, or rejected with reasons). That way we would not end up with hundreds of abandoned tickets (and just as many disillusioned contributors).

      • Helen Hou-Sandi 1:43 pm on June 8, 2014 Permalink | Log in to Reply

        Patch review from anybody in the community, particularly those who have more patches under their belt, is immensely helpful. While I wouldn’t expect that to fix the issue of ticket and patch rot completely, as I don’t think any one thing can, it really does go a long way toward helping ease the bottleneck that comes from an expectation that every single patch be reviewed by whatever is defined as the core team.

        • Bryan Petty 2:58 pm on June 8, 2014 Permalink | Log in to Reply

          This report is filtered specifically down to bugs only. There’s actually another 750 tickets with unreviewed patches for enhancements and new features. The reason the list is filtered, and why this is a high priority report is because assuming the core team doesn’t have the time to review everyone’s patch, it’s not a problem, features can still go in a plugin most of the time. I don’t expect the team to review every single patch. However, you can’t do that with bug fixes, and if developers with commit access can’t even keep up with reviewing bug patches (which account for less than 50% of the unreviewed patches), the team needs some serious reform.

          It’s one thing to ignore a bug report because you don’t have the time or required information to investigate it (and I get that), but it’s not acceptable when those with commit access on an open source project can’t be bothered to review patches. It’s literally the only job developers with commit access are absolutely required to do because no-one else can do it. Anyone else can fix the same issues and develop the same new features the core team has been working on if they’d let them. What the community can’t do is review and commit patches.

          It’s pathetic because someone else already did most of the heavy lifting, and it’s arrogant because the team assumes that only those with commit access have the ability to write quality patches. Above all else though, it’s a terrible cycle of abuse that WordPress is stuck in because someone invested a lot of their own (and their company’s) time writing it, and by ignoring it, the core team has consistently discouraged new contributors from getting involved. It’s also telling companies that hiring contributors or giving their developers extra time to contribute is just a waste of time and money. And without those dedicated long-term contributors, it becomes even more difficult to find worthy developers to grant commit access, and the team fails to find the time to review more patches yet again.

          You’re assuming that patch rot is a regular and normal thing in an open source project, and that’s partly true, but not to this extent. There’s a serious problem here, and there *are* solutions to that problem that the core team isn’t adopting.

          • Eric Andrew Lewis 4:20 am on June 9, 2014 Permalink | Log in to Reply

            I think you do have a point, but I don’t think grandstanding and talking trash at length about the process is productive.

            • Denis de Bernardy 9:26 pm on June 14, 2014 Permalink

              Imho, he’s absolutely not talking trash. He’s simply laying things out as they are. The issue got raised every year or so since 2005, and things haven’t changed to date except for the addition of extra committers — something yours truly vocally fought for. Fixing bugs is still lowest priority for all intents and purposes, and it’s shameful. I’m not holding my breath for things to change this year any more than it did when I abandonned the idea of contributing to WP in any material manner, but seeing a committer, however junior, actually initiate the discussion is a very welcome ray of light imho.

        • Robert Chapin 4:44 pm on June 8, 2014 Permalink | Log in to Reply

          I agree with Bryan. This is an area where the community has made incremental yet inadequate changes over the years. We have a well-organized Trac, unit testing to prevent old bugs from returning, and a core team willing to listen now, but bug fixes still take the absolute last priority in WordPress. The untapped potential of this community is mind boggling.

    • Tom Lynch 11:05 pm on June 7, 2014 Permalink | Log in to Reply

      I have been advocating changes to the Settings API and actually using it or providing hooks or something to the Admin settings and Network admin settings for years and it seems like someone higher up needs to make some decisions and garner support for it, because people have submitted patches only to be told we need to do XYZ… It’s hard to believe core still uses table based forms.

    • prionkor 6:48 am on June 8, 2014 Permalink | Log in to Reply

      Here is mine :) do_shortcode() for caption text. Was mentioned in dev chat.

      https://core.trac.wordpress.org/ticket/24990

    • leemon 8:16 am on June 8, 2014 Permalink | Log in to Reply

      https://core.trac.wordpress.org/ticket/5809 Updating a term in one taxonomy affects the term in every taxonomy
      https://core.trac.wordpress.org/ticket/23292 Media uploader loads full size image and slows down, please change to thumbnails.

    • Torsten Landsiedel 12:38 pm on June 8, 2014 Permalink | Log in to Reply

      It is not my ticket, but I think it would be hilarious to fix these: https://core.trac.wordpress.org/ticket/17268

      It seems to be a little bit tricky to check if the server does provide the right languages and modules, but maybe these plugins help to bring this into core:
      https://wordpress.org/plugins/native-gettext-diagnosis/
      http://wordpress.org/plugins/wp-performance-pack/

      Less memory usage and faster sites for non-english WP installations is maybe not important for many english developers and so it this seems to be lost in the last 4 years. Would be cool if this would gain more community power ;)

    • Robert Chapin 4:33 pm on June 8, 2014 Permalink | Log in to Reply

      Wouldn’t it be nice if 4.0 was a community-driven quality assurance release?

      #10041 This is my highest priority and must not wait for betas.

      These were punted from 3.9:
      #23185 – NBSP compat for dashes.
      #27587 – NBSP compat for smilies.
      #27588 – NBSP compat for shortcodes.
      #19550 – Filter wptexturize.

      I have several patches for problems that are being caused by wptexturize:
      #12690 Do not texturize HTML and shortcode elements! (Fixes several tickets)
      #19308 Do not texturize hexadecimal expressions.
      #8775 Fix curly quotes around numbers.
      #22823 Fix possesive numbers.

      The wptexturize tickets below can be ready for 4.0, but I’m not going to waste time on them if we can’t get the above tickets finished first.
      https://core.trac.wordpress.org/ticket/28483 Stack errors in wptexturize.
      #20342 Allow dashes before curly quotes.
      https://core.trac.wordpress.org/ticket/6969 Duplicates several other tickets, just needs review.
      https://core.trac.wordpress.org/ticket/4539 Duplicates several other tickets, just needs review.
      https://core.trac.wordpress.org/ticket/17571 Probably invalid.

    • Till Krüss 1:11 am on June 9, 2014 Permalink | Log in to Reply

    • Lachlan MacPherson 9:13 am on June 9, 2014 Permalink | Log in to Reply

      Would really love to see this ticket looked at: https://core.trac.wordpress.org/ticket/17379 (Filtered exports drop attachments and featured images).

      It’s something that I encounter many times a week.

    • Chris Van Patten 12:28 pm on June 9, 2014 Permalink | Log in to Reply

      Not my ticket, but I’d kill (not literally) for #21195: https://core.trac.wordpress.org/ticket/21195 As far as I can tell, there’s currently no clean way to get an avatar URL without leaning on regex, which is not fun.

    • Rodrigo Primo 1:49 pm on June 9, 2014 Permalink | Log in to Reply

      Thanks for asking Scott.

      The highest priority ticket for me is a better algorithm for listing hierarchical post types in the admin. This ticket has a patch and is waiting for core developers feedback.

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

    • Aubrey Portwood 4:03 pm on June 9, 2014 Permalink | Log in to Reply

    • Amanda Rush 6:26 pm on June 9, 2014 Permalink | Log in to Reply

      I think it would be great if 4.0 were a release that focused on accessibility. The media library has several problems just by itself, and we have of course been working on this along with testing core features for accessibility. Plus, by making 4.0, (or some other release if that’s not possible), an accessibility release, more credibility would be lent to WordPress as a platform that is serious about accessibility.

    • Knut Sparhell 10:32 pm on June 9, 2014 Permalink | Log in to Reply

      It’s a bit late to change the focus for 4.0 now. I would like to suggest 4.1 to focus on fixing bugs, bringing down the number of open tickets, and continue making internationalisation, password handling, multisite and taxonomies better according to the roadmaps lined out on this blog.

      My only open ticket with a patch is https://core.trac.wordpress.org/ticket/27951

    • Jesper Johansen (jayjdk) 8:12 pm on June 10, 2014 Permalink | Log in to Reply

      I’d love to get some kind of feedback on my patch on https://core.trac.wordpress.org/ticket/16784

    • Patrick Hesselberg 8:15 am on June 11, 2014 Permalink | Log in to Reply

      Adding a composer.json to WordPress core would still be awesome. *bump*
      https://core.trac.wordpress.org/ticket/23912

    • Ben Huson 11:15 am on June 11, 2014 Permalink | Log in to Reply

      Would appreciate any devs who have a good knowledge of how the Media Modal works giving their input/views/suggestions on this:
      https://core.trac.wordpress.org/ticket/28053

    • Vincent Mimoun-Prat 8:41 pm on June 11, 2014 Permalink | Log in to Reply

      I have submitted patches for that one and that would help plugins depending heavily on post meta. Query can go from hundreds of seconds to a few ms with that optimisation.

      https://core.trac.wordpress.org/ticket/24093

    • programmin 4:42 am on June 16, 2014 Permalink | Log in to Reply

      I consider this to be a serious regression in 3.9:
      https://core.trac.wordpress.org/ticket/28169

      In earlier versions the edit/delete buttons for shortcode placeholders were duck-punch-able to allow custom edit/delete behavior, but you must now resort to uglier workarounds in 3.9. Is there a good reason the developers don’t want the edit/delete buttons to be consistently used for shortcodes introduced by other plugins?

    • Tunbosun Ayinla 5:36 pm on July 13, 2014 Permalink | Log in to Reply

      I will appreciate a follow up for my patch https://core.trac.wordpress.org/ticket/24398

  • Scott Taylor 9:59 pm on May 7, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Multisite: let’s arrange office hours 

    I am envisioning lots of updates to Multisite for 4.0. @johnbillion and @jeremyfelt have been taking the lead. We should meet (at least) weekly to check in, plan work, and track progress. Not too formal, just to keep it in motion.

    Questions:
    When is a good time to meet?
    Who would like to be involved?

    Leave a comment / suggestion.

    There is no master plan. There is a make/core post: http://make.wordpress.org/core/2013/10/06/potential-roadmap-for-multisite/

    Let’s discuss.

     
  • Scott Taylor 5:43 pm on March 11, 2014 Permalink
    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.

    • manuelmasia 4:40 pm on April 19, 2014 Permalink | Log in to Reply

      Is there any way to filter the box to add some fields: besides “Autoplay” and “Loop”? I would like to add the ability to select the video start volume and another field to define whether to use the video as background (according with a theme I’m working on). Is there any tutorial or resources? TIA, Manuel :-)

  • Scott Taylor 9:04 pm on February 20, 2014 Permalink
    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?

    • cebab-pl 10:06 am on May 9, 2014 Permalink | Log in to Reply

      Hi Scott!
      How can i add thumbnail video (may by icon post for video) for a playlist video?
      I don’t want title files, but i want image (poster)

  • Scott Taylor 8:23 pm on January 29, 2014 Permalink
    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
    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

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