Make WordPress Core

Updates from Konstantin Kovshenin Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Kovshenin 11:20 am on April 11, 2014 Permalink
    Tags: , , ,   

    Plupload 2.x in WordPress 3.9 

    Plupload is the library that powers most of the file upload interfaces in WordPress, and in 3.9 we’ve updated the bundled library to version 2.1.1 (#25663). Here are some of things that have changed, which may affect WordPress plugins and themes.

    If you’re using direct references to Plupload’s runtime .js files, such as plupload.html5.js, note that these files are now gone. The following script handles were removed: plupload-html5, plupload-flash, plupload-silverlight and plupload-html4. If you need to enqueue the Plupload library, just use the plupload handle.

    If you’re constructing your own Plupload settings array vs. using wp_plupload_default_settings() and/or the _wpPluploadSettings object, note that some of the arguments have changed, most notably:

    • flash_swf_url should point to the new Moxie.swf file (See update)
    • Similarly, silverlight_xap_url should use the new Moxie.xap (See update)
    • The multiple_queues argument is no longer used
    • The max_file_size key has been moved to the filters array
    • The filters array now supports multiple keys, and the list of file types array has been moved to its mime_types key

    To illustrate that with code:

    $settings = array(
        // ...
        'flash_swf_url' => includes_url( 'js/plupload/plupload.flash.swf' ), // Unchanged
        'silverlight_xap_url' => includes_url( 'js/plupload/plupload.silverlight.xap' ), // Unchanged
        'filters' => array( 
            'max_file_size' => $max_upload_size . 'b', 

    Plupload version 2.1.1 has also added some exciting new options and methods, which you can find in the updated documentation.

    As a result of this update in WordPress 3.9 we were able to add drag and drop upload support directly to our TinyMCE editor (#19845), and we’ve also added a new boolean flag to wp_editor(), which you can use to enable drag and drop upload support in your own instance of the editor (#27465):

    wp_editor( '', 'my-editor', array(
        // ...
        'drag_drop_upload' => true,
    ) );

    If you run into any problems with this update in 3.9, please leave a comment on this post and we’ll be happy to help you out!

    Update: I opened #27763 to address some of the compatibility issues around the update. We might be renaming the swf/xap files for backwards compatibility.

    Update, April 13: The original swf/xap filenames were restored.

    • Andrew Nacin 1:20 am on April 14, 2014 Permalink | Log in to Reply

      Post updated to reflect changes via #27763.

    • experiencedbadmom 11:54 am on April 18, 2014 Permalink | Log in to Reply

      Thank you for the link to the manual instructions. My blog is experiencedbadmom.com tho, not experiencedbadmom.com/wordpress/ – does that matter? Also, one of the steps says to deactivate plugins – how am I to deactivate plugins if I can’t even get into my dashboard? GoDaddy is my host – do I deactivate plugins somewhere on their servers?

    • Najeeb 6:16 am on April 21, 2014 Permalink | Log in to Reply

      Hello there,

      well I am using pluploader library in my plugin and when try ‘plupload’ handle to use shipped scripts it not applying to my uploader object, even I can see libraries are loading. Any help will be much appreciated.


      • Konstantin Kovshenin 7:32 am on April 21, 2014 Permalink | Log in to Reply

        Hi there! Can you please provide more details, like a code sample? Also, has it worked in 3.8 and broken in 3.9 or does it just not work in general? Thanks!

    • pbusardo 7:13 pm on April 21, 2014 Permalink | Log in to Reply

      Perhaps this is relevant. I believe the FLA gallery uses Plupload. When I try to upload multiple files to the gallery, the GUI no longer appears.

  • Konstantin Kovshenin 3:02 pm on March 27, 2014 Permalink
    Tags: , ,   

    Masonry in WordPress 3.9 

    If you use Masonry in your themes or plugins, here’s what you should know about the 3.9 update.

    In WordPress 3.9 we’ve updated Masonry to v3, which no longer requires jQuery. The new script handle is masonry. Some of you have been using that very same handle with your own bundled copies of jQuery Masonry v2, this has potential to break in fairly rare cases:

    • You’re using Masonry v2 options or methods that are deprecated in v3
    • You’re dumping your Masonry init code inside the bundled library itself
    • You’re using v2 class names in CSS such as .masonry-brick and .masonry
    • You’re relying on a declared jquery dependency for masonry, even if you bundled v3

    The older jquery-masonry handle is now the official v2/v3 shim, which provides (some) backwards compatible options, methods and classes. If you were using core’s jquery-masonry in your theme or plugin, you should be fine. It’s also the handle you’ll want to use to be compatible with both 3.8 and 3.9+. A short Masonry v2 to v3 upgrade guide could be found here.

    Whatever you’re doing with Masonry in WordPress, we urge you to test your themes and plugins now. Get the latest beta and head over to #27510 to let us know if you’ve stumbled across any compatibility issues.

  • Konstantin Kovshenin 11:45 am on January 29, 2013 Permalink
    Tags: ,   

    Editorial Flow office hours, today (Tuesday) at 1800 UTC.

    I’ve been working on some mockups over the weekend of possible UI implementations for revising published content. Still very draft and a bunch of unanswered questions, nonetheless here are some pictures:

    So the agenda for today’s office hours is to discuss these, and maybe pick a direction (even if it’s totally different from the list above). Since there’s an overlap with the Revisions team, would appreciate if @westi and/or @ethitter popped in.

    • John Blackbourn (johnbillion) 1:38 pm on January 29, 2013 Permalink | Log in to Reply

      My vote goes to the first option (http://cl.ly/image/1b401P3B0d3U) which looks like it’ll work well and is surprisingly intuitive.

    • berkun 5:45 pm on January 29, 2013 Permalink | Log in to Reply

      Two thoughts:

      1. Overall the first option seems simplest (assuming these are 4 alternative designs). Only question is why the last screen is needed. It seems each of the options that show under the ‘More’ dropdown is already present. (UI redundancy can be ok, but not sure why it’s needed here)


      2. In the first design details of the publishing status disappear on the 3rd screen. Saying “This version is unpublished” expresses less information than the previous state, where it says “Published on Jan 1st. 12:54”.

      That loss in detail might be fine if we’re certain the user knows they’re working on a revision of something already published and the time it happened is irrelevant. But ideally we’d find an elegant way to tell them both info about when the original was published, *and* info that the current revision is unpublished.

      We could say:

      This version is unpublished
      Last version published at 1/21 12:45

      There’s a small can of worms here in how the schedule field behaves. It’s the only place the last published time appears, yet it goes away depending on what options the user has set.

      • Konstantin Kovshenin 6:07 pm on January 30, 2013 Permalink | Log in to Reply

        Cool, thanks for the feedback Scott! We discussed this briefly in IRC, everybody seemed to like the first version, or at least the direction. We’ll be working on it in #23314 if you’re interested. From the mockup, “view published version” actually links to the same Edit Post screen, only of the published version, so it isn’t really the preview changes button, but yes, all other options are redundant šŸ™‚

    • Justin Sternberg 6:35 pm on January 31, 2013 Permalink | Log in to Reply

      The publish metabox is already a bit unwieldy without these updates for the standard blogger. What do we think about simplifying the metabox (even more than it currently is) but add functionality in the form of a click to expand type of UI?

    • Justin Sternberg 6:37 pm on January 31, 2013 Permalink | Log in to Reply

      **sorry, bad grammar** “The publish metabox is already a bit unwieldy for the standard blogger without these updates.”

      • adamsilverstein 6:42 pm on January 31, 2013 Permalink | Log in to Reply

        i was thinking the same thing, as were also talking about trying to cram a ‘revisions’ link in there on the revisions refresh.

        i like the idea of hiding with a click to expand functionality, and also the idea of really simplifying the publish box – all most users need is publish or update; move the other functionality to another box called ‘Drafts & Revisions’…

      • Justin Sternberg 6:49 pm on January 31, 2013 Permalink | Log in to Reply

        I’m not sure this is the proper time/place to discuss this, but I like the idea of a post status bar? Like a bar above title/metaboxes that displays info like published date, publish status, revision status, post-format, etc (think browser status bars). Then that info can be removed from the publish metabox and other metabox displaying post info (or hidden in a click-to-expand section of the metabox) and give the user a high-level overview of the post’s status.

        • Daniel Bachhuber 6:55 pm on January 31, 2013 Permalink | Log in to Reply

          Iā€™m not sure this is the proper time/place to discuss this, but I like the idea of a post status bar?

          Could you share a mockup or wireframe? Also, it sounds like this could be built as a plugin first for user testing / viability purposes.

    • adamsilverstein 6:54 am on February 1, 2013 Permalink | Log in to Reply

      i created a new ticket (#23352) to track proposed changes to the publish box from the revisions team that relate to your workflow mockups. what do you think of simplifying publish and moving functionality to a new publish options box?

    • adamsilverstein 6:58 am on February 1, 2013 Permalink | Log in to Reply

      -> #23352

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar