WordPress.org

Make WordPress Core

Opened 22 months ago

Last modified 18 months ago

#21085 new enhancement

Better XML-RPC media handling

Reported by: markoheijnen Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.3
Component: XML-RPC Keywords: mobile 2nd-opinion
Focuses: Cc:

Description

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

Attachments (1)

patch-core-21085-wp_deleteMediaItem-1.diff (1.7 KB) - added by koke 20 months ago.

Download all attachments as: .zip

Change History (17)

comment:1 maxcutler22 months ago

  • Cc maxcutler added

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

comment:2 isaackeyet22 months ago

  • Cc isaackeyet added

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

comment:3 markoheijnen21 months ago

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

comment:4 markoheijnen21 months ago

  • Summary changed from mw_newMediaObject needs more functionality to Better XML-RPC media handling

comment:5 martythornley21 months ago

  • Cc marty@… added

comment:6 daniloercoli21 months ago

  • Cc ercoli@… added

comment:7 pento21 months ago

  • Cc gary@… added

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

comment:8 koke20 months ago

  • Cc jbernal@… added
  • Keywords mobile added

comment:9 koke20 months ago

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

Last edited 20 months ago by koke (previous) (diff)

comment:10 nacin20 months ago

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

comment:11 follow-up: nacin20 months ago

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

comment:12 in reply to: ↑ 11 koke20 months ago

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

comment:13 nacin19 months ago

  • Keywords 2nd-opinion added

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.

comment:14 nacin19 months ago

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.

comment:15 markoheijnen18 months ago

  • Type changed from defect (bug) to enhancement

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.

comment:16 markoheijnen18 months ago

  • Milestone changed from 3.5 to Future Release
Note: See TracTickets for help on using tickets.