WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 9 months ago

#13509 new defect (bug)

Searching doesn't return Private results to logged in users with read_private_ permissions

Reported by: inbytesinc Owned by: ryan
Milestone: Future Release Priority: normal
Severity: normal Version: 2.9.1
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description

When you do a search with these requirements...

  • You are a registered user.
  • You are logged in.
  • You have read_private_posts permissions.

... you expect seeing in the results those Private posts that contains your query's terms.

But you end up with showing only the ones that belongs to you. I think the bug is in these lines:

if ( is_user_logged_in() ) {
	$where .= current_user_can( "read_private_{$post_type_cap}s" ) ? " OR $wpdb->posts.post_status = 'private'" : " OR $wpdb->posts.post_author = $user_ID AND $wpdb->posts.post_status = 'private'";
}

As $post_type_cap is set to "any" when you do a search, the conditional expression always fails as it's asking for this:

current_user_can( "read_private_anys" )

... and ends up always in the second part of the conditional expression. That is:

" OR $wpdb->posts.post_author = $user_ID AND $wpdb->posts.post_status = 'private'"

Thanks.

Attachments (1)

13509.diff (1.4 KB) - added by leogermani 9 months ago.
implementing dd32's suggestion

Download all attachments as: .zip

Change History (8)

comment:1 dd324 years ago

  • Component changed from Query to Post Types
  • Keywords needs-patch added; query search private logged removed
  • Milestone changed from Unassigned to 3.0

The only solution to this i can think of is going to be something like the following, the current check for a cap and setting the SQL isnt going to work with custom post_types..

foreach ( post_types as type )
  if ( user can read private <type> )
    append to post_types_readable array
$sql .= " OR ($wpdb->posts.post_status = 'private' AND post_type IN (<post_types_readable array>)" 

Setting to 3.0 for now, but will need a patch rather soon to get in.

comment:2 inbytesinc4 years ago

  • Cc ramiro@… added

comment:3 ryan4 years ago

  • Milestone changed from 3.0 to 3.1

comment:4 kevinB4 years ago

  • Cc kevinB added

comment:5 nacin3 years ago

  • Milestone changed from Awaiting Triage to Future Release

dd32's change makes sense.

comment:6 leogermani9 months ago

  • Cc leogermani added
  • Keywords has-patch added; needs-patch removed

leogermani9 months ago

implementing dd32's suggestion

comment:7 leogermani9 months ago

patch updated after nacin's feedback

Note: See TracTickets for help on using tickets.