Better XML-RPC media handling

[markoheijnen]

In 3.4 there was a lot of improvements. For 3.5 I would like to see some major improvement in wp.uploadFile and metaWeblog.newMediaObject.

At this moment you can't insert a description, alternate text or caption. ( #5461/#18684 ). Also the file can't be attached to a post ( #13917 ).

The overwrite functionality also doesn't work ( #17604 ). Not sure why this exists since WordPress itself doesn't do this.

Also the current way isn't how WordPress does it internally. wp_handle_upload() doesn't get used (#6559).

There is also going on something wrong with mime types ( #12518 ).

Also the work from 3.4 should be implemented ( #6430 ).

Last thing is that WordPress normally also looks at the EXIF information. At this moment the XML-RPC also doesn't do that ( #18087 )

rarely related: #12493 - filter for wp_upload_bits

I worry that it will be difficult to add new features and fix all of these issues without breaking existing clients. Media uploading is already a problematic area for many clients, and trying to patch wp.uploadFile/mw.newMediaObject without breaking things is likely not worth the effort.

Instead, I propose that we add a new method for creating and editing media/attachments that is better aligned with modern core functionality:

• Create a new wp.newMediaItem method for uploading files.
• Create a new wp.editMediaItem method for editing existing media files.
• Create a wp.getMediaItems alias for the existing wp.getMediaLibrary method.
• Deprecate wp.uploadFile and mw.newMediaObject (though all of mw.*, mt.* and blogger.* should be deprecated).

+1 for an updated way to handle new media items specifically. Images should be attachable to posts directly.

There should also be an method for removing a media item. See #5310

Related - adding resumable upload support to the XML-RPC API: #21497

Added patch with wp.deleteMediaItem. I wonder if that method should have an extra $force_delete argument (see ​wp_delete_attachment)

The same parameter should be added to wp.deletePost. Currently it must be called twice to delete the post, as the first one trashes.

Note also that attachments do not have trash enabled, so wp.deleteMediaItem should not actually bother with a force_delete for now.

Replying to nacin:

Note also that attachments do not have trash enabled, so wp.deleteMediaItem should not actually bother with a force_delete for now.

OK, the docs for wp_delete_attachment made me think otherwise

The cap check here should be delete_post, $post_id. And in that case, the cap check should come before the invalid ID check.

Not sure why wp.deleteMediaItem should be needed — wp.deletePost is functionally equivalent. At most wp.deleteMediaItem should be an alias.

I see a lot of tickets listed in the description here, but few of them are currently slated for 3.5, and few have any recent activity. Not sure what else to do here.

I punted it for now. It's something that need to be discussed more but way to late for 3.5 since it's an enchantment of the existing API.