WordPress.org

Make WordPress Core

Opened 4 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:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.2.1
Component: Query Keywords: has-patch needs-unit-tests
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 4 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 in reply to: ↑ description @SergeyBiryukov4 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.

comment:2 @GaryJ4 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.

@SergeyBiryukov4 years ago

comment:3 @SergeyBiryukov4 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.

comment:4 @GaryJ4 years ago

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

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

comment:5 @l3rady3 years ago

  • Cc scott@… added

comment:6 @wonderboymusic23 months 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

comment:7 @wonderboymusic22 months ago

  • Keywords needs-unit-tests added

comment:8 @nacin21 months 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 21 months ago by nacin (previous) (diff)

comment:9 @jeremyfelt21 months ago

Related publicly_queryable discussion in #19693

Note: See TracTickets for help on using tickets.