[wp-trac] [WordPress Trac] #29660: Functions in wp_includes/query.php assume non-null return value from get_queried_object
WordPress Trac
noreply at wordpress.org
Tue Sep 29 05:31:07 UTC 2020
#29660: Functions in wp_includes/query.php assume non-null return value from
get_queried_object
-------------------------------------------------+-------------------------
Reporter: yellyc | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Future
| Release
Component: Query | Version: 4.0
Severity: normal | Resolution:
Keywords: 2nd-opinion has-patch has-unit- | Focuses:
tests |
-------------------------------------------------+-------------------------
Comment (by dd32):
Ran into this on WordPress.org, started a PR, found this ticket and merged
[attachment:"query-patch.diff"] into [https://github.com/WordPress
/wordpress-develop/pull/556 PR 556].
The unit test shows the absurdity of this, but it kind of makes sense.
There's two different kinds of checks being asked for here:
- `is_page()` - Is this request for a page? Might be a 404, and that's
okay.
- `is_page( 'page-name' )` - Is this a request for THIS page name? (Can
never be true for a 404)
So as a result, having a page query for `page-name` that 404's is still a
page request, but it's ''not'' a `page-name` page request as the request
404'd.
I think based on the above logic this is probably safe and ideal to be
fixed in this manner, however, I would not be against having all of these
fields set to `false` when `is_404()` - but that only happens for the main
query, not for new queries like in this unit test (A stand-alone query is
never a 404, only a zero-results query).
--
Ticket URL: <https://core.trac.wordpress.org/ticket/29660#comment:38>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list