Direct WP_Query::get_posts() calls can break

[nacin]

global $wp_query;
$wp_query->set('cat', '-13');
$posts = $wp_query->get_posts();

That worked in 3.0, and fails in 3.1. With parse_query() never getting called, now parsed_tax_query() never gets called. Previously enough logic was in get_posts() for this to work. It was inconsistent because parse_query() was circumvented, but it worked.

In IRC he planned out a strategy of sorts and Ryan is going to work up a patch later.

[nacin]

Original report: ​http://wordpress.org/support/topic/wp_query-exclude-categories-not-working?replies=4

[scribu]

I don't think this warrants 'blocker' status, but I guess that doesn't make much of a difference.

[markjaquith]

There's my suggestion.

[jane]

"That worked in 3.0, and fails in 3.1."

@scribu: an unintentional regression is generally a blocker.

[scribu]

My point was that, like ryan said, it shouldn't have worked ever. parse_query() and get_posts() should have been private from the beginning. (Captain Hindsight to the resque, I know.)

[ryan]

Avoids calling init() from parse_query() and stomping query vars that have been set(). query() now handles init() and query/query_vars setup. The $query arg to parse_query() is now optional. It is never passed by core code and could probably be gotten rid of, but it is still handled in case a plugin is calling it directly for whatever mysterious reason.

Note that using the set(), get_posts() style requires running init() yourself if you want to do another query with the same query object . This was true in 3.0 as well.

[ryan]

The $parsed_query flag is probably not needed now, but I left it in.

[scribu]

In get_posts(), $this->parsed_query is set to false, just after it's set to true in parse_query(). Is that intentional?

[scribu]

Nevermind, of course it's intentional. But what's the point in having it? Less code = less bugs.

[ryan]

Without parsed_query flag

[markjaquith]

Ryan, what's the test case that your patch passes but mine doesn't?

[ryan]

	$query = new WP_Query;
	$query->set('cat', 4);
	$posts = $query->get_posts();

With your patch all set()s are stomped.

[ryan]

Do the query from an init hook. It will always fail. A query run after the big query that reuses the big query object could sometimes work (although anyone doing that really should call init() before hand). My patch should work either way.

[ryan]

Testing should be done with a clean object and a dirty object that has already run a query.

[ryan]

(In [17451]) Run parse_query() in get_posts() so that the query vars are always parsed for set(), get_posts() patterns. fixes #16545 for trunk

[ryan]

(In [17452]) Run parse_query() in get_posts() so that the query vars are always parsed for set(), get_posts() patterns. fixes #16545 for 3.1

[nacin]

This broke get_posts(). #16575

[ryan]

(In [17455]) Use ->query instead of . Always kick off the parse_query action. fixes #16545 for trunk

[ryan]

(In [17456]) Use ->query instead of . Always kick off the parse_query action. fixes #16545 for 3.1

[mikeindustries]

What's the latest on this? Appreciate everyone's work but kind of sucks that WP 3.1 was released with this as a known problem. Everyone who upgraded to 3.1 and had been excluding categories is now unintentionally polluting their public RSS feeds with unexpected content. This is the first time I've upgraded WordPress and regretted it :(.

Thanks in advance for the help.

[nacin]

It's not a known problem. The ticket is closed as fixed.

What is your code?

[SergeyBiryukov]

​http://wordpress.org/support/topic/wp-31-breaks-rss-customization-via-exclude_category

[markjaquith]

Opened #16622 to track this bug.