[wp-trac] [WordPress Trac] #21394: query.php: get_queried_object() result cannot be assumed to be non-NULL

[WordPress Trac]

#21394: query.php: get_queried_object() result cannot be assumed to be non-NULL
--------------------------+------------------------------
 Reporter:  lkraav        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Query         |     Version:  3.3.2
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+------------------------------
Description changed by SergeyBiryukov:

Old description:

> I'm dealing with a WPMUdev plugin called MarketPress. Its
> /store/products/ page is a special CPT catalog thing that seems to have
> wp_title() issues, so I dug into it.
>
> Turns out that:
>
> is_front_page() -> is_page() -> $page_obj = $this->get_queried_object()
> -> $page_obj == NULL
>
> But is_page() (and other is_...()) go harrassing $page_obj assuming
> there's always something useful there. This creates a flood of "non-
> object access" notices.
>
> I would expect something like this to make sense in these is_...()
> functions:
>
> {{{
> if (!is_null($page_obj)) return false;
> }}}
>
> Since WP_Query::get_queried_object() first sets its result as null and
> returning a value is actually conditional, I don't see a way around these
> checks. Enlighten me please if I'm wrong.
>
> I've looked at #19035, #18164, #17662. All of them are situations where
> there's at least something there in $page_obj. None of them seem to
> discuss or patch NULL values.
>
> I discovered this on 3.3.2, but todays trunk [source:trunk/wp-
> includes/query.php at 21248#L3340] has the same code.

New description:

 I'm dealing with a WPMUdev plugin called MarketPress. Its /store/products/
 page is a special CPT catalog thing that seems to have wp_title() issues,
 so I dug into it.

 Turns out that:

 is_front_page() -> is_page() -> $page_obj = $this->get_queried_object() ->
 $page_obj == NULL

 But is_page() (and other is_...()) go harrassing $page_obj assuming
 there's always something useful there. This creates a flood of "non-object
 access" notices.

 I would expect something like this to make sense in these is_...()
 functions:

 {{{
 if (!is_null($page_obj)) return false;
 }}}

 Since WP_Query::get_queried_object() first sets its result as null and
 returning a value is actually conditional, I don't see a way around these
 checks. Enlighten me please if I'm wrong.

 I've looked at #19035, #18614, #17662. All of them are situations where
 there's at least something there in $page_obj. None of them seem to
 discuss or patch NULL values.

 I discovered this on 3.3.2, but todays trunk [source:trunk/wp-
 includes/query.php at 21248#L3340] has the same code.

--

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21394#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software