Opened 7 years ago

Closed 7 years ago

#2613 closed defect (bug) (fixed)

Don't show private posts on front page

Reported by: ryan Owned by: ryan
Priority: normal Milestone: 2.1
Component: Administration Version: 2.1
Severity: normal Keywords: query private performance
Cc:

Description

Showing a user's private posts on the front page seems to cause more confusion than good. People mistakenly conclude that anyone can see their private posts. Let's show private posts only in the admin and when directly visiting the permalink. Also, allow users who have the capabilities to edit others posts to see anyone's private posts. No one can hide from the editor.

This will also simplify our front page query a bit. Simpler is betterer-er.

Attachments (3)

private_query.diff (1.2 KB) - added by ryan 7 years ago.
private.diff (3.8 KB) - added by ryan 7 years ago.
No private posts in main query. Add private post/page caps.
private.2.diff (1.5 KB) - added by ryan 7 years ago.
Restore private posts on front page and label them

Download all attachments as: .zip

Change History (19)

ryan7 years ago

I'd prefer to visibly mark them Private, much like we do with Protected posts. Can have a filter so themers can define their own Private icon if they like.

That might cause even more confusion, as users will be used to protected posts showing up on their front page, and draw a direct comparison.

Showing a user's private posts on the front page seems to cause more confusion than good.

Agreed. I can't tell you how many times people have frantically said that their private posts were exposed to the world or exposed via their RSS feed and I've had to explain to them that they are the only ones that can see it.

Also, allow users who have the capabilities to edit others posts to see anyone's private posts. No one can hide from the editor.

Disagree here. This muddies the distinctions between private and drafts, especially for a "submit drafts for publish" model. Users need a way of keeping stuff private before they ready it for the editors.

"Disagree here. This muddies the distinctions between private and drafts, especially for a "submit drafts for publish" model. Users need a way of keeping stuff private before they ready it for the editors."

Yeah, that's drafts. Drafts are a message to the editor to say "don't read this stuff yet, it isn't ready". Private posts are in the realms of the published, and as such should be visible/editable by the editor.

The issue I have them with being author/editor-viewable Private posts comes when people use your machine. I imagine that 95% of WP users stay logged in all the time; if you're hiding the Private posts from folks close to you, you end up needing to use a belt-and-suspenders approach and pass-protect private posts in case you don't secure your terminal around the house.

You're saying that if you're an editor and you leave your terminal unprotected, then a malicious family member could read people's private posts? I think you've got bigger problems if that's the case.

David: Perhaps, but the issue is in the use of the term "private". Additionally, if Ryan's comment about simplifying the front page query is right, I can't see where this is a bad decision.

Yeah, that's drafts. Drafts are a message to the editor to say "don't read this stuff yet, it isn't ready". Private posts are in the realms of the published, and as such should be visible/editable by the editor.

If you are a user with publishing capability and can only submit drafts for review, how are you to distinguish between "This is ready for publishing" and "I'm still working on this"? That's the niche I see private posts filling.

Mark, okay, nice idea. I can't imagine any scenario where it would be appropriate for an editor to edit a user's private post, so I'm with you. (Any time you can think of, it would probably be a more appropriate job for an administrator).

gfmorris, seriously, if you have powers to edit any post and you leave you terminal unprotected you're asking for trouble. A malicious user wouldn't bother editing private posts, he'd go straight for the published ones and the big red 'Delete' button.

map_meta_cap() already checks for read_private_posts and read_private_pages. These are not currently assigned to any of the default roles. Let's add edit_private_posts, edit_private_pages, delete_private_posts, and delete_private_pages to the map_meta_cap() checks and leave policy up to the admin. Admin can assign these caps to users and roles as desired. By default, no roles will have any of these capabilities, although it can be argued that an administrator should be able to do anything to any post or page.

We might do this on wp.com given the number of support requests about it. I think it would be a good idea for WP core. I'll put up a new patch with the map_meta_cap changes for your consternation.

ryan7 years ago

No private posts in main query. Add private post/page caps.

Patch removes private posts from front page query and adds caps for editing/deleting/reading private posts and pages. Admin is given these caps by default. No other role can read/edit/delete other user's private posts.

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

(In [3772]) Remove private posts from front page query. Aadd private posts and page caps. fixes #2613

Pendulum action: now some WP.com folks are complaining about their private posts disappearing from the main query.

get_the_title() marks posts that have passwords. This could be done for Private posts. Wouldn't this solve the problem (confusion) without upsetting either camp? (I don't consider the user worried about people using his logged-in computer a camp, sorry gfmorris. Log out.)

ryan7 years ago

Restore private posts on front page and label them

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 2.0.2 to 2.1

I think you're right. Check out this patch.

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

Patch applied as part of changeset [3900]

Note: See TracTickets for help on using tickets.