Make WordPress Core

Opened 12 years ago

Closed 12 months ago

Last modified 11 months ago

#13509 closed defect (bug) (fixed)

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

Reported by: inbytesinc Owned by: boonebgorges
Milestone: 5.7 Priority: normal
Severity: normal Version: 2.9.1
Component: Posts, Post Types Keywords: has-patch needs-refresh
Focuses: Cc:


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'"


Attachments (1)

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

Download all attachments as: .zip

Change History (16)

#1 @dd32
12 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.

#2 @inbytesinc
12 years ago

  • Cc ramiro@… added

#3 @ryan
12 years ago

  • Milestone changed from 3.0 to 3.1

#4 @kevinB
11 years ago

  • Cc kevinB added

#5 @nacin
11 years ago

  • Milestone changed from Awaiting Triage to Future Release

dd32's change makes sense.

#6 @leogermani
8 years ago

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

8 years ago

implementing dd32's suggestion

#7 @leogermani
8 years ago

patch updated after nacin's feedback

#8 @ryan
7 years ago

  • Owner ryan deleted
  • Status changed from new to assigned

#9 @chriscct7
6 years ago

  • Keywords needs-refresh added

#10 @samful
18 months ago

While looking into ticket 46968 https://core.trac.wordpress.org/ticket/46968. I encountered the exact issue that @inbytesinc did. I googled "read_private_anys" and got here.

I realised that this is related and that this patch will solve both issues.

Last edited 18 months ago by samful (previous) (diff)

#11 @boonebgorges
12 months ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from assigned to closed

In 49830:

Query: Respect post-type specific capabilities when querying for multiple post types.

After this change, the relevant read_private_posts capability is checked for
each queried post type. This ensures that private posts appear in search and
archive queries for users who have the ability to view those posts.

Props leogermani.

Fixes #13509, #48968, #48556.

#12 @SergeyBiryukov
12 months ago

  • Milestone set to 5.7

#13 @peterwilsoncc
12 months ago

In 49832:

Coding Standards: Minor fixes following [49830].

See #13509, #48968, #48556.

#14 @peterwilsoncc
12 months ago

In 49833:

Coding Standards: Minor fixes following [49830].

Fixes the fixes missed in [49832]. They are fixed now.

See #13509, #48968, #48556.

#15 @peterwilsoncc
11 months ago

This was caused by the same underlying issue as #48556.

I'll be reverting the commit [49830] as it introduces a bug for unregistered post types but I will leave this ticket closed as most discussion has occurred on #48556.

Note: See TracTickets for help on using tickets.