Reusing the Media Upload kit in a plugin

[simonwheatley]

I'm keen to reuse the Media Upload overlay (i.e. the thickboxed iframe from the edit post/page screens) when I need to upload files for a plugin. It seems crazy to be reimplementing file upload and image resizing code when it's built into WordPress core. However the hooks aren't there currently.

The attached proof of concept plugin "rmu-poc.php" shows that it is possible to write a plugin which pops up the upload overlay (install it and go to the edit category screen), but a number of issues prevent it being useful:

The form is setup to be called in the context of the edit post/page screen, for example the JS callback expects to find a function send_to_editor which will accept it's HTML.

It would be handy to insert some additional post fields to be sent when the SWF Uploader uploads files, so the plugin can detect that it should be doing something with that upload.

The get_media_item function needs a way to customise the button label. Currently the proof of concept does a very ugly hack on a translation filter.

Before I get over excited, is anyone up for these changes? If I started cutting some patches, would they be considered?

[Denis-de-Bernardy]

+1

[nacin]

Fine idea in theory, but we're planning to entirely rewrite media/upload in a future release, which would probably include dropping thickbox in place of an inline uploader, etc... And so I think we would be disinclined to create more points for plugins to hook into a system when we'd break them in the next two major versions.

I would think that given our current development philosophy, nothing we'd build wouldn't be extendable the way you'd want it.

[filosofo]

Replying to nacin:

Fine idea in theory, but we're planning to entirely rewrite media/upload in a future release, which would probably include dropping thickbox in place of an inline uploader, etc... And so I think we would be disinclined to create more points for plugins to hook into a system when we'd break them in the next two major versions.

I would think that given our current development philosophy, nothing we'd build wouldn't be extendable the way you'd want it.

Well, this is a snippet from an IRC conversion on October 17, 2008, the first mention of media being handled in the next version of WordPress (that grep finds for me; public logs don't seem to go back that far).

Oct 17 03:34:56 <DD32>  Ah cool, At least there'll be something left over for 2.8
Oct 17 03:35:15 <janeforshort>  media, media, media and fixing widget management, plus probably inbox

And since there's talk now of using 3.1 to focus on WordPress.org, qua the website not the app, that would put the great media revolution off at least until 3.2, which if history is a guide will arrive a year from now.

All that to say, let's not trade concrete suggestions for vaporware.

[johnbillion]

If the media system does get an overhaul and moves to something inline rather than modal, there's still a case for what Simon is suggesting. A system allowing plugins to easily provide a modal media browser/uploader would be great.

[nacin]

Replying to johnbillion:

If the media system does get an overhaul and moves to something inline rather than modal, there's still a case for what Simon is suggesting. A system allowing plugins to easily provide a modal media browser/uploader would be great.

Correct. I hinted to this in the last paragraph of my comment.

Replying to filosofo:

And since there's talk now of using 3.1 to focus on WordPress.org, qua the website not the app, that would put the great media revolution off at least until 3.2, which if history is a guide will arrive a year from now.

I would place money on the suggestion that the next major release focusing on feature development (whenever it is) will include a media/upload focus.

[filosofo]

Replying to nacin:

I would place money on the suggestion that the next major release focusing on feature development (whenever it is) will include a media/upload focus.

Sure, but that's something that will appear in 2011. Let's fix the problems we have, and in the future we can deprecate for the new-and-improved system.

As a wise man once wrote,

It’s called iteration. In an open source project, iteration happens very publicly. ... It’s called a patch for a reason. As we evolved the custom post type system, tons of code got rewritten, some of it dating three years and some of it three days. As we merged in WordPress MU, thousands of lines of code written by Donncha and contributors to MU were in some cases entirely rewritten or simply deprecated and removed. This is how a project evolves, grows, and strengthens.

[nacin]

Replying to filosofo:

Replying to nacin:
Sure, but that's something that will appear in 2011. Let's fix the problems we have, and in the future we can deprecate for the new-and-improved system.

As a wise man once wrote,

Touche. :-) Though I would be weary of introducing hooks that we'd then need to support (or, drop, after only one version, if we even release 3.1 versus just stretch the cycle) through what I'd hope to be a complete change to how media works in terms of both UI and API.

[simonwheatley]

So... can I push the case for a patch with a light touch, which would enable us to use the media upload kit elsewhere? I've extended my test code (see amended attached proof of concept plugin) and patched the current trunk in as few places as possible to get it working... two proposed new filters to be exact (see attached diff).

The two proposed new filters are:

swfupload_post_params - This allows you to add to or alter the post fields which SWFUpload posts to the server along with the file. Guessing at the future, I'd say this filter would be reusable on the new system Nacin mentions unless we don't end up keeping SWFUpload as the file upload provision.

swfupload_success_handler - This allows you to filter the name of the JS function passed to SWFUpload, which it calls on successful upload. Again, if SWFUpload remains a provision for uploading files then I'd argue that amending this function name would be necessary in the future system.

How does that sound?

[simonwheatley]

OK. Now I look at the diff I see three new filters, sorry for the confusion, the third being:

get_media_item_args - This allows you to filter the arguments passed to get_media_item, and I propose using this to set "send" to true so that the action button (named "Insert into Post" when uploading images for posts) is not supressed.

[simonwheatley]

OK. Now we're looking at 3.1 in earnest I want to push the case for a light touch patch here... just three filters, what do people say?

(I'm aware I'm pushing it, particularly with Jane's comments on ​Process and Scope.)

[scribu]

Looks good to me. Hooks are generally welcome, regardless of scope.

[mikeschinkel]

+1 on adding to 3.1.

[hakre]

+1 for everything that brings this forward. maybe there is some json function artifact in core that is helpful for your patch. *maybe*

[jane]

I don't have any objection to adding hooks, and since this patch was updated 2 months ago, if it's sound I'd like to get it in if it can go in today (entering beta).

[simonwheatley]

Proof of concept plugin - now with more descriptive description

[simonwheatley]

Three proposed new filters for media.php - patch refreshed to current trunk

[simonwheatley]

Nearly missed Jane's coment...

Patch refreshed to current trunk, no changes apart from line numbers and some context. Everything still works. Added some description to the proof of concept plugin.

Can we get this in before beta? Please? :)

[nacin]

Don't see much of a problem with this.

[ryan]

(In [16476]) get_media_item_args, swfupload_post_params, and swfupload_success_handler filters. Props simonwheatley. fixes #13817