Keep private posts in the admin area / Was: Make private posts a canonical plugin

[Denis-de-Bernardy]

Said Matt:

Also, a lot of the complexity of private posts could be avoided by a relatively simple change: saying they're only viewable in the dashboard. (Which I think is close to how people use them already.)

---

There are quite a few tickets related to private posts that can be viewed by users who should, and even more tickets related to private comments that can be viewed by users who aren't authorized to view the post.

There also is at least one ticket that highlights a performance issue related to private posts.

​http://core.trac.wordpress.org/search?q=private

Would it be an option to turn this into a canonical plugin and begone with the problems?

[Denis-de-Bernardy]

A few tickets for reference:#11695, #11375, #9499, #9347, #9211, #9144, #9136, #9125... the list (and the confusion) goes on, and on...

[ericmann]

Considering the majority of users (at least the majority of users I have contact with) don't even use the private post functionality, I see the logic in moving it to a canonical plug-in. However, that doesn't address any of the underlying visibility or performance issues.

[miqrogroove]

+1 Even though I have to set Private if I want to make a test post without publishing it, the reality is I never do that kind of testing on a production website.

[Denis-de-Bernardy]

Replying to ericmann:

However, that doesn't address any of the underlying visibility or performance issues.

True, but that would be the canonical plugin's team worry, rather than our own.

[Denis-de-Bernardy]

see #11375 in particular on the performance problem (I closed it as dup of this)

[ericmann]

In the interest of moving all of the private posts functionality to a canonical plugin, would someone mind pointing me in the direction of existing code? I can probably find most of it on my own ... but a head start would be nice.

[Denis-de-Bernardy]

Replying to ericmann:

In the interest of moving all of the private posts functionality to a canonical plugin, would someone mind pointing me in the direction of existing code? I can probably find most of it on my own ... but a head start would be nice.

Searching the code base for 'private' and "private" gives a good starting point. Basically, it leads you to:

• admin ajax
• the post and page editors (including a js file)
• meta boxes api
• admin templates (lists and inline edit)
• comments api (e.g. posting on private posts)
• capabilities
• xmlrpc
• importers

I think that the importers can safely be left untouched.

The rest would basically need to be replaced with appropriate filters. Make sure this gets blessed by a core dev before you start, however.

[matt]

I think this is worth discussing, but I feel like we should prove core plugins work with post-by-email and a few other pilots before re-examining other functionality.

Also while I doubt almost anyone on Trac will appreciate private posts, a lot of people use them extensively.

[matt]

Also, a lot of the complexity of private posts could be avoided by a relatively simple change: saying they're only viewable in the dashboard. (Which I think is close to how people use them already.)

[Denis-de-Bernardy]

Replying to matt:

Also, a lot of the complexity of private posts could be avoided by a relatively simple change: saying they're only viewable in the dashboard. (Which I think is close to how people use them already.)

I'd mega +zillions that particular idea.

[Denis-de-Bernardy]

keep private posts in the admin area, per Matt's suggestion

[Denis-de-Bernardy]

Replying to matt:

Also, a lot of the complexity of private posts could be avoided by a relatively simple change: saying they're only viewable in the dashboard. (Which I think is close to how people use them already.)

I've attached a patch (untested) that aims to do just that, in case anyone wants to test it.

[sillybean]

I disagree with Matt's assumption that people use private pages this way. It's certainly not how my organization does things. We're using them to create a small, simple intranet. We've granted subscribers the read_private* capabilities. They don't have permission to write anything, and we don't want them to have to learn their way around the Dashboard. They should be able to use the regular site menu, with the private pages visible once they're logged in. (We don't have them go through the Dashboard to log in; we're using the Sidebar Login plugin.)

How would this patch work in the situation where someone has permission to read private content, but not edit it?

[Denis-de-Bernardy]

see also #11914, where the performance issue is very clear

[sillybean]

Replying to Denis-de-Bernardy:

see also #11914, where the performance issue is very clear

Unless I'm reading that wrong, private posts are not the culprit there.

[Denis-de-Bernardy]

#11914 is about three things: a missing index, doing 20 queries where a single one would fit. the private posts query additionally introduces an OR statement in the query.

you're reading right: the proper fix would be to deal with the first two points.

if we don't, however, another potential fix would be to drop the OR statement, so as to use the type_status_date index.

[dd32]

Punting to 3.1 as its missed the boat for any form of implementation.

[Amieiro]

I think the private post functionality has its proper usage. V.gr., I use it to have published content that I can only see if I am logged in the WordPress, so I think that if they are only viewable in the dashboard, it will affect some users that are using it as private information repository, as @sillybean mention above.

I think we should remove this ticket as #wontfix.