Make WordPress Core

Opened 13 years ago

Last modified 3 years ago

#18513 new defect (bug)

Searching with explicit post types unsets page post type

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

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 13 years ago.

Download all attachments as: .zip

Change History (12)

#1 in reply to: ↑ description @SergeyBiryukov
13 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
13 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
13 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
13 years ago

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

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

#5 @l3rady
12 years ago

  • Cc scott@… added

#6 @wonderboymusic
11 years ago

  • Milestone changed from Awaiting Review to 3.7

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

#7 @wonderboymusic
11 years ago

  • Keywords needs-unit-tests added

#8 @nacin
11 years ago

  • Milestone changed from 3.7 to 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 11 years ago by nacin (previous) (diff)

#9 @jeremyfelt
11 years ago

Related publicly_queryable discussion in #19693

#10 @chriscct7
9 years ago

  • Keywords dev-feedback added

#11 @SergeyBiryukov
3 years ago

#55155 was marked as a duplicate.

Note: See TracTickets for help on using tickets.