'exclude_from_search' excludes from non-search queries

[danblaker]

Any WP_Query using 'post_type' = 'all' will only return post types where 'exclude_from_search' is FALSE. I would expect 'post_type' = 'all' to include all post types, *except* when initiated via a front-end search.

Recommend adding an is_search() check when excluding post types from a 'post_type' = 'all' query.

[kawauso]

Apply exclude_from_search only when is_search() for post_type & post_status

[ocean90]

Also running in this problem today, because when exclude_from_search is true also the archive page is empty.

[kawauso]

Replying to ocean90:

Also running in this problem today, because when exclude_from_search is true also the archive page is empty.

Just curious why you used the is_search() function shorthand over the method of the current query?

[ocean90]

Just ignore my patch. :)

[mitchoyoshitaka]

Kawauso, looks good to me. Note that your patch doesn't apply cleanly after #18364.

[ryan]

Introduced in r13052 and as far as I recall was done on purpose. Regardless, I don't think we can change the meaning of 'any' at this point. We probably need a way to ask for all public types and all types.

[kawauso]

Post-#18364 refresh

[duck_]

Replying to ryan:

Introduced in r13052 and as far as I recall was done on purpose.

And r11998 for the post_type query variable.

I ran across this whilst testing a term archive for a custom taxonomy registered to a custom post type with exclude_from_search == false (public => false, but publicly_queryable => true).

[netweblogic]

Whilst working on my plugin, I had to make a workaround. This seems to work:

function my_cp_parse_query( ){
        global $wp_query;
        //Search Query Filtering
        if( !empty($wp_query->query_vars['s']) && $include_in_search ){
                $wp_query->query_vars['post_type'] = array_diff( get_post_types(array('exclude_from_search' => false)), array('my_custom_post'));
        }
}
add_action('parse_query','my_cp_parse_query');

It just checks to see if a search is being made, if so, get all the searchable post types and remove yours from the list, supplying that array to post_type query var. Hope that helps someone!

[l3rady]

I just came across this and it took me hours for me to work it out.

I had a CPT called locations and had 'exclude_from_search' => true. I then created a custom taxonomy for this CPT called ltypes. I then created taxonomy-ltypes.php to list all posts that have the chosen taxonomy, only to be greeted with no posts found...

[aaroncampbell]

Replying to ryan:

Introduced in r13052 and as far as I recall was done on purpose. Regardless, I don't think we can change the meaning of 'any' at this point. We probably need a way to ask for all public types and all types.

I think it's really common to have a post type you DON'T want in searches but you DO want taxonomy pages for. Maybe in query.php where we check if ($this->is_tax) and set $post_type = 'any'; we could instead set it to whatever post types the taxonomies support? Or possibly set it to 'all' and add another condition that uses get_post_types() instead of get_post_types( array('exclude_from_search' => false) );

[aaroncampbell]

By the way, the workaround I used was to show 'news' posts on the 'news_item_cat' taxonomy pages. I did it like this:

function pd_only_query_tickers( $q ) {
	if ( is_tax( 'news_item_cat' ) )
		$q->set( 'post_type', 'news' );
}
add_filter( 'pre_get_posts', 'pd_only_query_tickers' );

[ruud@…]

Ran into this also. Tried to use the exclude_from_search on a cpt but found out archives/categories are empty. Going to try the workarounds.

[wonderboymusic]

17592.3.diff​ would alter current behavior. If that is not tenable, this ticket should be closed as wontfix

[boonebgorges]

See also #29418.

While I agree that we probably can't change the existing behavior of 'exclude_from_search', we might think about introducing more properly-named and fine-grained params for this sort of thing, and maybe even deprecating (while continuing to support) exclude_from_search.

[boonebgorges]

Closing due to backward compatibility issues spelled out above. See #29418 for discussion of potential enhancements that would serve as a workaround to the current problem.