Make WordPress Core

Opened 8 years ago

Last modified 5 years ago

#37917 new defect (bug)

Users without the edit_private_posts capability can still create private posts

Reported by: ryankanner's profile ryan.kanner Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 2.1
Component: Posts, Post Types Keywords: 2nd-opinion
Focuses: administration Cc:


Currently, users without the "edit_private_posts" capability, can still view the "Private" radio button under "Visibility". They can also save / publish the post (depending on their capabilities) with no issue. The same goes for pages as well with the "edit_private_pages" capability. I think it's reasonable enough to assume that users that don't have the "edit_private_{post_type}" capability, shouldn't be able to create posts with a visibility of private.

Attachments (1)

37917.patch (2.6 KB) - added by ryan.kanner 8 years ago.

Download all attachments as: .zip

Change History (5)

8 years ago

#1 @akibjorklund
8 years ago

Hi @ryan.kanner, welcome to the WordPress Trac! Thanks for your report and for taking the time to create a patch.

While your assumption is indeed very reasonable, I think this is at least partly intended behavior. It is just unintuitive and does not allow fine grained enough control. That is, if I'm understanding things right after doing some research on the subject.

Users, who have the capability to publish_posts, but do not have edit_published_posts, can publish posts. They just can't edit them afterwards without the capability. Similarly, it makes sense that users cannot edit private posts afterwards without edit_private_posts. But alas, there is no separate make_posts_private (the equivalent to publish_posts for private posts).

When trying to publish or make posts private without publish_posts their status status is set to pending in wp-admin/includes/post.php. XML-RPC does it's own similar validation, but throws an error. REST API too requires `publish_posts` for private status.

So the publish_posts capability is used instead to also cover cases where status is changing to private. It makes sense, because if this capability is missing, none of the visibility choices would appear. For more fine-grained control, a new capability would have to be introduced. And that would have to be enforced in many more places than on the UI level. XML-RPC and REST API included.

I'm not totally convinced it makes sense to tie publish_posts with making posts private, but that is how it works and it is would probably be very hard to change. So if we were to introduce make_posts_private, then that would have to depend on publish_posts.

I think the next step would be to hear some arguments why such new capability would need to exist, other than just for completeness (which would be a valid reason to me). What are the use cases for this? What sort of harm is done if people with publish_posts can also set status to private? If there is not much harm and the thinking behind the tickets is just to prevent users accidentally setting posts to private, creating a plugin that hides the options with CSS based on for example a custom capability or a user role would do just fine. (It is another issue altogether, but personally I think private posts don't have much use, so they mostly just clutter the UI.)

Version 0, edited 8 years ago by akibjorklund (next)

This ticket was mentioned in Slack in #core by helen. View the logs.

8 years ago

#3 @jnylen0
8 years ago

  • Version changed from trunk to 2.1

This likely dates back to the introduction of edit_private_posts in 2.1 (

#4 @desrosj
5 years ago

  • Keywords 2nd-opinion added
Note: See TracTickets for help on using tickets.