Make WordPress Core

Opened 15 years ago

Last modified 21 months ago

#18513 new defect (bug)

Searching with explicit post types unsets page post type

Reported by: GaryJ Owned by:
Priority: normal Milestone:
Component: Query Version: 3.2.1
Severity: normal Keywords: has-patch needs-unit-tests dev-feedback
Cc: Focuses:

Description

Tested on WP 3.2.1, Twenty Eleven with no plugins, multisite.

If I explicitly limit a search query via a GET request using an array of post_type values, the post_type for page is automatically excluded.

To reproduce:

or

​http://example.com/?post_type[]=post&post_type[]=page&post_type[]=book&s=Test

That's searching for "Test" on post, page and attachment/book post types.

  • Adding the following to a theme's functions.php:
    add_filter( 'pre_get_posts', 'wpcpt_search' );
    /**
     *
     * @param array $query
     */
    function wpcpt_search( $query ) {
    
    	if ( ! $query->is_search )
    		return $query;
    
    	print_r( $query->query_vars );
    
    	return $query;
    
    }
    

That spits out (and seemingly confirmed via the values shown in the Debug Bar plugin) the following at the beginning:

  Array ( [s] => Test [post_type] => Array ( [0] => post [2] => attachment ) 

and only returns results for posts and attachments (or books). The fact that key 1 is missing makes me think that page was in the array at some point, but it's been unset, but I can't see where, or why, this might be done.

(When no post_type is set, giving a post_type of 'any', which in turn gives all of the non-excluded_from_search post types, then page is one of the array values, and the search results correctly include pages.)

Attachments (1)

18513.patch​ (754 bytes ) - added by SergeyBiryukov 15 years ago.

Download all attachments as: .zip

Change History (13)

#1 in reply to: ↑ description @SergeyBiryukov
15 years ago

Replying to GaryJ:

The fact that key 1 is missing makes me think that page was in the array at some point, but it's been unset, but I can't see where, or why, this might be done.

​http://core.trac.wordpress.org/browser/tags/3.2.1/wp-includes/class-wp.php#L280

Pages are not publicly queryable (see [18234], #17040), so they are excluded.

#2 @GaryJ
15 years ago

Well, I'll be. I looked at that post type registration and missed the publicly_querable line. Thank you.

In that case then, why does the Page appear in the search results when there's no post_type set? The Debug Admin Bar gives part of the Query SQL as:

...AND wpgt_posts.post_type IN ('post', 'page', 'attachment', 'class', 'function', 'hook', 'book')...

It's this discrepancy which is odd.

#3 @SergeyBiryukov
15 years ago

  • Keywords has-patch added

Non-publicly queryable post types are only excluded from post type queries, that doesn't prevent them to appear in a regular search results (without post_type constraints).

Perhaps they shouldn't be excluded when searching, though. Here's a patch for that.

#4 @GaryJ
15 years ago

Edited. (Invalid question after re-reading the above comment several times.)

Last edited 15 years ago by GaryJ (previous) (diff)

#5 @l3rady
14 years ago

  • Cc scott@… added

#6 @wonderboymusic
13 years ago

  • Milestone Awaiting Review → 3.7

Patch still applies cleanly, I tested it, fixes the issue, moving to 3.7 for discussion

#7 @wonderboymusic
13 years ago

  • Keywords needs-unit-tests added

#8 @nacin
13 years ago

  • Milestone 3.7 → Future Release

This change is scary, and could also result in private post types being exposed. Major issue. "page" is an exception we may need to manually add. publicly_queryable is a mess, we need to figure out what to do here.

Last edited 13 years ago by nacin (previous) (diff)

#9 @jeremyfelt
13 years ago

Related publicly_queryable discussion in #19693

#10 @chriscct7
11 years ago

  • Keywords dev-feedback added

#11 @SergeyBiryukov
5 years ago

#55155 was marked as a duplicate.

#12 @codente
21 months ago

Can there be movement on this so it can be resolved?

Note: See TracTickets for help on using tickets.