Thanks for the information. It wasn’t exactly what I was looking for, but it proved to be quite useful. First, how the query changes depending on permalinks being enabled. It first seemed impossibly mysterious. It’s quite simple really. It has to do with $wp->parse_request(). With no permalinks, the parser has to use what is passed in the request. With permalinks, it can use rewrite rules to transform what is passed in the request into different query vars.
Thus, the difference is sort of a red herring, we are essentially starting with different query vars under each condition. Neither is necessarily wrong, just different. Where things go wrong is how the query is formed with each set of query vars. To stay sane, I’m backtracking on my previous idea to focus on the different permalink forms. We need to pick one or the other and get it working. It doesn’t matter what the other does, since we are not going to use it.
I’m going to focus on permalinks enabled, as that is what I and most people use. If you normally have them disabled, similar debugging path is still followed, but the specific query vars you start with are different. With permalinks enabled, you get 404 errors, nothing is returned. Examining the query tells us why. It specifically wants a post with the name ‘site-permalink’ among other things, like post meta ‘_post_meta_key’ must equal ‘1’ for this post. If either of these are not true, nothing is returned. Not knowing how the query vars were established, I can’t say how this query got to be this way. Maybe you recognize something here that will lead to a solution.
The other thing happening is the setting of the post_type var to include ‘partner’ is not happening, probably because of what is returned by $wp_query->get_queried_object(). More than likely NULL is returned. This method continues to have issues even though the category issue was fixed. The inline docs list what sorts of queries the method works for: category, tag, taxonomy, posts page, single post, page, or author. About half of these do not work!
The whole thing is a kludge really. It makes no sense to get a queried object in ‘pre_get_posts’ because we haven’t queried anything yet, so how can we have an object? A bunch of work around code was put in place so developers using ‘pre_get_posts’ have something to work with in setting or unsetting query vars for certain conditions. The workaround code was to only apply for the most commonly used queries, more obscure queries are out of luck.
Except we are now out of luck because the code provided doesn’t even work half the time. I suggest you give up on $wp_query->get_queried_object() and get the values you need by other means. There’s nothing magical about this method. You can get values needed just as well as it can. It’s nice having everything in one place, but it’s more efficient to only get what you need and forget the rest. For inspiration on how to get certain values, see the source code in query.php, line 3262.
Keep in mind some of the techniques may not work, so you may need to find related alternatives just as the category patch did. I don’t have a specific patch for $wp_query->get_queried_object(), but I intend to do more research and reopen the related Trac ticket. That is unless you would rather do it.
