WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#12498 closed defect (bug) (fixed)

wp_write_post() isn't custom post type friendly

Reported by: ceenz 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)

12498.diff (955 bytes) - added by scribu 4 years ago.
fix wp_write_post() cap check

Download all attachments as: .zip

Change History (13)

comment:1 scribu4 years ago

  • Keywords needs-patch added

Yes, it should.

comment:2 ceenz4 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).


comment:3 scribu4 years ago

I think there already are checks of this form:

current_user_can("edit_published_{$post_type}")

(I might be wrong)

comment:4 voyagerfan57614 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.

comment:5 mikeschinkel4 years ago

  • Cc mikeschinkel@… added

comment:6 sirzooro4 years ago

  • Cc sirzooro added

comment:7 Utkarsh4 years ago

  • Cc admin@… added

scribu4 years ago

fix wp_write_post() cap check

comment:8 scribu4 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.

comment:9 scribu4 years ago

  • Summary changed from wp permissions to wp_write_post() isn't custom post type friendly

comment:10 scribu4 years ago

  • Keywords commit added

comment:11 dd324 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..

comment:12 scribu4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

I just committed something very similar which fixes this ticket, [13729]

Closing it then.

Note: See TracTickets for help on using tickets.