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.

#3-9, #dev-notes, #editor, #tinymce

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 CSSCSS Cascading Style Sheets. 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s jquery-masonry in your theme or pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, 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.

#3-9, #dev-notes, #themes

Editorial Flow office hours today Tuesday at 1800…

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

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

  • The “Save as Draft” and “Publish Changes” flow: http://cl.ly/image/1b401P3B0d3U
  • “Update” vs “Save as Draft” with a drop-down button: http://cl.ly/image/2o0C3b3r252d
  • “Save Changes for Later” vs “Discard” in a drop-down button: http://cl.ly/image/0y0T0Y0H0M1X
  • Everything hidden in a misc-publishing-action: http://cl.ly/image/2J0e0A3N0F2b
  • What a contributor would see: http://cl.ly/image/1Q2V1Q3L3L46

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 RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. team, would appreciate if @westi and/or @ethitter popped in.

#3-6, #editorial-flow