Opened 15 years ago
Closed 15 years ago
#12498 closed defect (bug) (fixed)
wp_write_post() isn't custom post type friendly
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Posts, Post Types | Keywords: | has-patch commit |
Focuses: | Cc: |
Description
With customs post types shouldn't wp_write_post() check user permissions for editing all available post types and not just 'post' or 'page'?
Eg currently:
if ( isset( $_POSTpost_type? ) && 'page' == _POSTpost_type? ) {
if ( !current_user_can( 'edit_pages' ) )
return new WP_Error( 'edit_pages', ( ) );
} else {
if ( !current_user_can( 'edit_posts' ) )
return new WP_Error( 'edit_posts', ( ) );
}
Attachments (1)
Change History (13)
#2
@
15 years ago
- Summary changed from wp_write_post permissions to wp permissions
Discussion carried on from #9674.
I bring this up to highlight the current limitation of Roles and Capabilities in WP. In the above example while pages and posts appear distinct they are just different content types. current_user_can( 'edit_post', $post_ID ) is just looking at the $post_ID an whether or not the current user has the right to edit that individual content instance.
current_user_can( 'edit_posts' ) on the other hand is looking at whether or not the user has the privilege to edit content of the type 'post', as does 'edit_pages' etc.
I believe that the current designation of user capabilities need to be changed so that all available 'content types' can be assigned as different capabilities and roles.
I suggest that checking user capabilities such as 'edit_posts', and 'edit_pages' be replaced with a singular function call such current_user_can( 'edit_type', $content_type_ID ).
This can be repeated with other current user capabilities such as: edit_published_pages edit_published_posts
EG: change to current_user_can( 'edit_published_type', $content_type_ID )
delete_pages delete_posts
EG: change to current_user_can( 'delete_type', $content_type_ID )
publish_pages publish_posts
EG: change to current_user_can( 'publish_type', $content_type_ID )
These changes would also mean that when a custom content type is created / managed / deleted (etc) the user permissions for that type would also have to be set / managed / deleted (etc).
#3
@
15 years ago
I think there already are checks of this form:
current_user_can("edit_published_{$post_type}")
(I might be wrong)
#4
@
15 years ago
- Cc WordPress@… added
- Type changed from defect (bug) to enhancement
As I understand it, it's not so much whether the user can edit a specified content type, but rather whether the user can edit a particular piece of content. The differences in abilities for e.g. editing posts published by other users are, I believe, the reason that each piece of content is checked, rather than its type.
Note: I don't believe this is really a defect; changed to enhancement.
#8
@
15 years ago
- Keywords has-patch added; needs-patch removed
- Type changed from enhancement to defect (bug)
12498.diff fixes the original issue with wp_write_post().
ceenz, I recommend you create a _new_ ticket, instead of hijacking this one.
#9
@
15 years ago
- Summary changed from wp permissions to wp_write_post() isn't custom post type friendly
#11
@
15 years ago
This applies to a lot more than just wp_write_post.
I just committed something very similar which fixes this ticket, [13729]
admin-ajax.php could do with a lot of checks fixed there too.
I was thinking this could be handled better at the map_meta_cap level, but due to the ID's not being passed, I think its best that core just updates it to get the post object, and take it from there instead.
In short, anything which turns up in a grep(ignoring whitespace) for "current_user_can('edit_post" needs to be changed..
Yes, it should.