Make WordPress Core

Opened 13 years ago

Closed 9 years ago

Last modified 9 years ago

#17592 closed defect (bug) (wontfix)

'exclude_from_search' excludes from non-search queries

Reported by: danblaker's profile danblaker Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1.2
Component: Query Keywords: has-patch close
Focuses: Cc:

Description

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.

Attachments (4)

17592.diff (1.4 KB) - added by kawauso 13 years ago.
Apply exclude_from_search only when is_search() for post_type & post_status
17592.patch (1.2 KB) - added by ocean90 13 years ago.
17592.2.diff (1.5 KB) - added by kawauso 12 years ago.
Post-#18364 refresh
17592.3.diff (1.2 KB) - added by wonderboymusic 11 years ago.

Download all attachments as: .zip

Change History (27)

@kawauso
13 years ago

Apply exclude_from_search only when is_search() for post_type & post_status

#1 @kawauso
13 years ago

  • Keywords has-patch needs-testing added

@ocean90
13 years ago

#2 follow-up: @ocean90
13 years ago

  • Keywords needs-testing removed

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

#3 @ocean90
13 years ago

  • Cc nacin added
  • Milestone changed from Awaiting Review to 3.3

#4 in reply to: ↑ 2 @kawauso
13 years ago

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?

#5 @ocean90
13 years ago

Just ignore my patch. :)

#6 @mitchoyoshitaka
12 years ago

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

#7 follow-ups: @ryan
12 years ago

  • Milestone changed from 3.3 to Future Release

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
12 years ago

Post-#18364 refresh

#8 in reply to: ↑ 7 @duck_
12 years ago

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).

#9 @netweblogic
12 years ago

  • Cc msykes@… added

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!

#10 @l3rady
12 years ago

  • Cc scott@… added

#11 @l3rady
12 years ago

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...

#12 in reply to: ↑ 7 @aaroncampbell
12 years ago

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) );

#13 @aaroncampbell
12 years ago

  • Cc aaroncampbell added

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' );

#14 @ruud@…
12 years ago

  • Cc ruud@… added

#15 @ruud@…
12 years ago

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.

#16 @wonderboymusic
11 years ago

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

#17 @wonderboymusic
11 years ago

  • Keywords close added

#18 @jaredatch
11 years ago

  • Cc jared@… added

#19 @jadpm
10 years ago

  • Cc jadpm added

#20 @dgwyer
10 years ago

  • Cc d.v.gwyer@… added

#21 @boonebgorges
9 years ago

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.

#22 @boonebgorges
9 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

This ticket was mentioned in Slack in #core by ocean90. View the logs.


9 years ago

Note: See TracTickets for help on using tickets.