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

[maxcutler]

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).

[isaackeyet]

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

[markoheijnen]

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

[pento]

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

[koke]

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

[nacin]

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

[nacin]

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

[koke]

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

[nacin]

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.

[nacin]

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.

[markoheijnen]

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.

[chriscct7]

@markoheijnen did you want to continue persuing this?

[markoheijnen]

No need to continue pursuing this.