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

[josephscott]

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

[ericmann]

Updated diff looks good.

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

[ericmann]

Refresh patch to match latest version of trunk.

[ericmann]

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.

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

[ericmann]

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

[markoheijnen]

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.

[nacin]

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

[maxcutler]

Refresh + cap check

[maxcutler]

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

[nacin]

In [21896]:

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

[dd32]

#25290 was marked as a duplicate.