Opened 3 years ago

Last modified 3 years 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
Priority: normal Milestone: Future Release
Component: Post Types Version: 2.9.1
Severity: normal Keywords: needs-patch
Cc: ramiro@…, kevinB

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.

Change History (5)

comment:1   dd323 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.

  • Cc ramiro@… added

comment:3   ryan3 years ago

  • Milestone changed from 3.0 to 3.1
  • Cc kevinB added
  • Milestone changed from Awaiting Triage to Future Release

dd32's change makes sense.

Note: See TracTickets for help on using tickets.