WordPress.org

Make WordPress Core

Opened 9 years ago

Last modified 7 weeks ago

#11697 reopened defect (bug)

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

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

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 9 years ago.
keep private posts in the admin area, per Matt's suggestion

Download all attachments as: .zip

Change History (28)

#1 @Denis-de-Bernardy
9 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
9 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
9 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
9 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
9 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
9 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
9 years ago

  • Cc eric@… added

#8 in reply to: ↑ 6 @Denis-de-Bernardy
9 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
9 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
9 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
9 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
9 years ago

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

#12 in reply to: ↑ 10 @Denis-de-Bernardy
9 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
9 years ago

  • Owner ericmann deleted
  • Status changed from accepted to assigned

#14 @voyagerfan5761
9 years ago

  • Cc WordPress@… added

#15 @sillybean
9 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
9 years ago

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

#17 in reply to: ↑ 16 @sillybean
9 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
9 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
9 years ago

  • Keywords bug-hunt added

#20 @Denis-de-Bernardy
9 years ago

  • Keywords featured added; bug-hunt removed

#21 @dd32
9 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
8 years ago

  • Milestone changed from Awaiting Triage to Future Release

#23 @knutsp
8 years ago

  • Cc knut@… added

#24 @nacin
5 years ago

  • Component changed from General to Post Types

#25 @chriscct7
4 years ago

  • Keywords featured removed

#26 @iseulde
4 months ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

This ticket has not seen any activity in over *two* years, so I'm closing it as "wontfix".

The ticket may lack decisiveness, may have become irrelevant, or may not have gathered enough interest.

If you think this ticket does deserve some attention again, feel free to reopen.

For bugs, it would be great if you could provide updated steps to reproduce against the latest version of WordPress (5.0.2 at the time of writing). Remember images or a video can be superior to explain a problem. At the very least, quickly test again to make sure the bug still exists.

If it’s an enhancement or feature, some extra motivation may help.

Thank you for your contributions to WordPress! <3

#27 @JeffPaul
7 weeks ago

  • Keywords bulk-reopened added
  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened

A decision was made to reopen tickets that were closed in the bulk edit that this ticket was affected by. This ticket is being placed back into the Awaiting Review milestone so it can be individually evaluated and verified to determine if it is still relevant/valid or reproducible.

Note: See TracTickets for help on using tickets.