0

I had recently implemented custom Plupload form in a plugin (located in admin area and working with SVG files).

Plupload has half a ton of settings, provided for WP's own upload zone by wp_plupload_default_settings(), from which I had to copy settings out and customize.

Now in upcoming 3.9 core release those settings are getting changed (see Plupload 2.x in WordPress 3.9), which would likely blow my custom upload up, at least partially.

How do I implemented Plupoad in a way that won't fall apart every time core changes related bits and won't interfere with arbitrary upload zones in core or other plugins/themes?

This is settings I ended up with so far (they might not be perfect, but they got it done):

public function get_uploader_settings() {

    return array(
        'runtimes'            => 'html5,silverlight,flash,html4',
        'browse_button'       => 'cdd-plupload-browse-button',
        'container'           => 'cdd-plupload-upload-ui',
        'drop_element'        => 'cdd-drag-drop-area',
        'file_data_name'      => 'async-upload',
        'multiple_queues'     => true,
        'max_file_size'       => wp_max_upload_size() . 'b',
        'url'                 => admin_url( 'admin-ajax.php' ),
        'flash_swf_url'       => includes_url( 'js/plupload/plupload.flash.swf' ),
        'silverlight_xap_url' => includes_url( 'js/plupload/plupload.silverlight.xap' ),
        'filters'             => array( array( 'title' => __( 'Allowed Files' ), 'extensions' => 'svg' ) ),
        'multipart'           => true,
        'urlstream_upload'    => true,
        'multi_selection'     => false,
        'multipart_params'    => array(
            '_ajax_nonce' => wp_create_nonce( 'media-form' ),
            'action'      => 'upload-attachment',
            'post_id'     => get_the_ID(),
            'cdd-upload'  => true,
        ),
    );
}
  • Hey @Rarst, can you provide a little bit more details on what exactly breaks? Is it just the swf/xap URLs an the max filesize filter or is there something else? It'd be also helpful if you provided some sample code and we can try to figure some back-compat things out. Thanks! – kovshenin Apr 11 '14 at 16:37
  • @kovshenin added settings-related code to the question. I hadn't tested this out with 3.9 since essentially this is part of completed work-for-hire, which I am not currently working on (likely to be working on it further though in near future). – Rarst Apr 11 '14 at 16:41
  • Cool! I can think of two potential solutions here. One is if core's wp_plupload_default_settings() function was simply more generic in a way you could use outside of wp.Uploader and wp.media. Second is to try and decouple wp.Uploader from media and have plugins use that instead. Inside we can provide back-compat code for things like max_file_size. Thoughts? – kovshenin Apr 11 '14 at 16:52
  • @kovshenin for starters I would be happy getting those $defaults from wp_plupload_default_settings() without its side effects. I could probably handle this in JS, but this assume native stuff is enabled, for generic case / public code would be too fragile. – Rarst Apr 11 '14 at 16:56
  • 2
    Actually 2.1.1 seems to provide backwards compatibility for max_file_size and filters ref, so I guess the only things we're missing are the paths to the swf/xap files... – kovshenin Apr 11 '14 at 16:57
1

Seems like core just needs a better way to handle backwards compatibility with Plupload at the WordPress level :) You as a plugin developer shouldn't have to worry about that, your usage looks fair, given that there currently is no other way to obtain that default settings array.

I've opened #27763 to address this and some other compatibility issues with the Plupload update. Feel free to add to the list if anything else pops up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.