#13917 closed task (blessed) (fixed)
wp.uploadFile cannot be attached to any post
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | XML-RPC | Keywords: | has-patch commit mobile |
Focuses: | Cc: |
Description
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
Attachments (4)
Change History (22)
#1
@
13 years ago
- Component changed from General to XML-RPC
- Milestone changed from 3.0.1 to Future Release
#9
follow-up:
↓ 10
@
11 years ago
- Cc marko@… added
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)
#10
in reply to:
↑ 9
@
11 years ago
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.
#11
follow-up:
↓ 12
@
11 years ago
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.
#12
in reply to:
↑ 11
@
11 years ago
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 IDcreate_attachment()
takes a post ID of 0wp_update_post()
passes whatever ID it received, most often an unsanitized$_REQUEST['post_id']
media_handle_upload()
handles things the same way aswp_update_post()
media_handle_sideload()
also handle things the same way aswp_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 ...
#13
@
11 years ago
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.
I'm fine with this change. I've included an updated diff.