[wp-trac] [WordPress Trac] #31355: Custom hierarchical post type 404s when `get_queried_object` is called too early

[WordPress Trac]

#31355: Custom hierarchical post type 404s when `get_queried_object` is called too
early
--------------------------+------------------------------
 Reporter:  gradyetc      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Query         |     Version:  3.0
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by boonebgorges):

 gradyetc - Thanks for the extremely thorough report.

 The fact that we set `$queried_object_id` in `parse_query()` is, as you
 note, the source of the anomaly. IMO, the fact that the query takes place
 here is a kind of bug. In theory, no queries should take place until after
 the query has been fully parsed; at `'parse_query'` and `'pre_get_posts'`,
 you'd be working with a query object whose properties were fully set, but
 where no results had yet been fetched. You have, in effect, suggested the
 opposite - that we should perform *all* single object queries in
 `parse_query()`, regardless of post type - but this seems like it only
 passes the buck to the next developer who is confused at the proper order
 of WP's bootstrap.

 The current behavior was introduced way back when [4956] as a way to
 support page_on_front. I just spent a little while trying to back it out -
 basically, converting the `get_page_from_path()` query in `parse_query()`
 so that it only sets a local variable, and then letting the actual page
 query take place in `get_posts()`. This would remove the exceptional
 behavior of single pages, and it would make it so that the `is_*()`
 functions would be unusable for *all* post types until after the full
 query had taken place. But making this change work requires some oddball
 property juggling, and I'm not sure that it won't introduce backward
 compatibility issues for plugins that expect 'pagename' to have been
 converted to `$queried_object_id` at `pre_get_posts`.

 Given the complexity of the situation, I'm leaning toward leaving the code
 the way it is, and updating the documentation so that we officially don't
 support the use of the conditional `is_*()` functions at 'pre_get_posts'
 or before. What do you think?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31355#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform