Die fast in get_posts if in_search_post_types returns nothing

[mitchoyoshitaka]

From a comment of mine in #18364, which nacin suggested was worth a follow-up ticket:

Just noticed that this logic here might in fact have a flaw: if there are no post types which have exclude_from_search = false, then magically *all* post types will be checked? Am I reading this right? In that case, shouldn't we just immediately return no results?

Obviously, this wouldn't be an issue except in a very customized setup where all post types have exclude_from_search = true, but still... thoughts anyone?

[mitchoyoshitaka]

This patch incorporates two decisions:

1. Whether to just kill the query immediately or to continue building the (no-row-returning) query. I believe we *should* continue to build the SQL query and let it run as some filter might come along and save the query, making it non-trivial.
2. How to create a . My first intuition was to always add null to the list of post_types in (), but then trivial cases such as post_types in (null, 'post') has the potential of being (probably only a little) slower than post_types in ('post'). The solution presented here just makes it post_types in (null) in cases when $in_search_post_types is empty.

Feedback welcome.

[nacin]

1=0 is generally how we kill a query.

[wonderboymusic]

Refreshed patch against trunk as it was blowing up - this one makes sense, moving to 3.7

[wonderboymusic]

In 25239:

Kill the query in the following edge case: post_type => 'any' but exclude_from_search => false returns no valid post types. Adds unit tests.

Props mitchoyoshitaka.
Fixes #19198.

[SergeyBiryukov]

In 28800:

Add @ticket references.

see #16854, #19198.