WordPress.org

Make WordPress Core

Opened 10 years ago

Last modified 5 months ago

#11697 assigned defect (bug)

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

Reported by: Denis-de-Bernardy Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Posts, Post Types Keywords: has-patch needs-testing
Focuses: Cc:
PR Number:

Description (last modified by 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?

Attachments (1)

11697.diff (728 bytes) - added by Denis-de-Bernardy 10 years ago.
keep private posts in the admin area, per Matt's suggestion

Download all attachments as: .zip

Change History (26)

#1 @Denis-de-Bernardy
10 years ago

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

#2 follow-up: @ericmann
10 years ago

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.

#3 @miqrogroove
10 years ago

+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.

#4 in reply to: ↑ 2 @Denis-de-Bernardy
10 years ago

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.

#5 @Denis-de-Bernardy
10 years ago

  • Keywords needs-patch added; 2nd-opinion removed

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

#6 follow-up: @ericmann
10 years ago

  • Owner set to ericmann
  • Status changed from new to accepted

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.

#7 @ericmann
10 years ago

  • Cc eric@… added

#8 in reply to: ↑ 6 @Denis-de-Bernardy
10 years ago

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.

#9 @matt
10 years ago

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.

#10 follow-ups: @matt
10 years ago

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.)

#11 in reply to: ↑ 10 @Denis-de-Bernardy
10 years ago

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
10 years ago

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

#12 in reply to: ↑ 10 @Denis-de-Bernardy
10 years ago

  • Description modified (diff)
  • Keywords has-patch needs-testing added; needs-patch removed
  • Summary changed from Make private posts a canonical plugin to Keep private posts in the admin area / Was: Make private posts a canonical plugin

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.

#13 @ericmann
10 years ago

  • Owner ericmann deleted
  • Status changed from accepted to assigned

#14 @voyagerfan5761
10 years ago

  • Cc WordPress@… added

#15 @sillybean
10 years ago

  • Cc steph@… added

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?

#16 follow-up: @Denis-de-Bernardy
10 years ago

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

#17 in reply to: ↑ 16 @sillybean
10 years ago

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.

#18 @Denis-de-Bernardy
10 years ago

#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.

#19 @Denis-de-Bernardy
10 years ago

  • Keywords bug-hunt added

#20 @Denis-de-Bernardy
10 years ago

  • Keywords featured added; bug-hunt removed

#21 @dd32
10 years ago

  • Milestone changed from 3.0 to 3.1

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

#22 @nacin
9 years ago

  • Milestone changed from Awaiting Triage to Future Release

#23 @knutsp
9 years ago

  • Cc knut@… added

#24 @nacin
6 years ago

  • Component changed from General to Post Types

#25 @chriscct7
4 years ago

  • Keywords featured removed
Note: See TracTickets for help on using tickets.