wp.uploadFile cannot be attached to any post

[ciprian_vb]

wp.uploadFile from xmlrpc.php saves each upload as an unattached file.

I wanted to attach it to a post once uploaded but a option for this does not exist and the $post_id is given the value 0 before wp_insert_attachment inside the $attachment array.

I am happy to make this enhancement if needed and approved but I'm not sure what the protocol is as this is my first time in doing this.

Thanks,
Ciprian Turcu

I'm fine with this change. I've included an updated diff.

Updated diff looks good.

Patch is fine with me. I only wonder if there should be a check if the post id that is given does exists and it's post type is public (way it works now in the back-end)

Refresh patch to match latest version of trunk.

Replying to markoheijnen:

Patch is fine with me. I only wonder if there should be a check if the post id that is given does exists and it's post type is public (way it works now in the back-end).

Actually, none of the references I can find to wp_insert_attachment(), which is the method we're using to insert the attachment, check this. They blindly pass along whatever post_id was passed in, which is typically $_REQUEST['post_id'] captured from somewhere else.

How I see it is that wp_insert_attachment() is a low level API so there are always checks needed. Same as for wp_insert_post.
So checking if it is allowed to do should be in the xmlrpc method. No clue how it got handled in the backend. I do now from the user interface you only can attach an image when the post type is a public one.

Replying to markoheijnen:

How I see it is that wp_insert_attachment() is a low level API so there are always checks needed. Same as for wp_insert_post.
So checking if it is allowed to do should be in the xmlrpc method. No clue how it got handled in the backend. I do now from the user interface you only can attach an image when the post type is a public one.

I agree that checks need to be added somewhere but I disagree that this is the right place for it. Take a look at other refs to wp_insert_attachment() for example:

• handle_upload() omits a post ID
• create_attachment() takes a post ID of 0
• wp_update_post() passes whatever ID it received, most often an unsanitized $_REQUEST['post_id']
• media_handle_upload() handles things the same way as wp_update_post()
• media_handle_sideload() also handle things the same way as wp_update_post()

So if we really need to be checking that the post exists and is public before attaching an image, that kind of logic should exist in wp_insert_attachment() itself, and should probably be a separate issue.

The front-end checks you're talking about are probably abstracted into the UI ...

I disagree with that. low level API's shouldn't have a lot of checks. Same that wp_insert_post doesn't do a lot of capability checking.

I do have to say I'm not sure if checking if a post type is public is a the good way of doing that.
I guess also in terms of permission checking it also is weird handeld.

Needs an edit_post check to make sure they can upload a file to that post.

Refresh + cap check

Refreshed the patch again and added the edit_post cap check as requested.

In [21896]:

Allow wp.uploadFile to upload the attachment to a post. props djzone, josephscott, maxcutler. fixes #13917.