[wp-trac] [WordPress Trac] #34373: Don't set is_home=>true in WP_Query during REST request

[WordPress Trac]

#34373: Don't set is_home=>true in WP_Query during REST request
--------------------------------------+------------------
 Reporter:  danielbachhuber           |       Owner:
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  4.4
Component:  REST API                  |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  dev-feedback needs-patch  |     Focuses:
--------------------------------------+------------------

Comment (by boonebgorges):

 > In a REST request, is_home should remain false as home isn't a defined
 context in a REST request.

 Is this true universally? Is there a legitimate use case for a "home"
 endpoint? If `WP_Query` hardcodes an `is_rest`, it's going to mean some
 awkward workarounds in the case where one actually wants to make a 'home'
 query in a REST request.

 Then again, `WP_Query` is terrible about mixing concerns in exactly this
 way. It's the whole purpose of `parse_query()`. `is_feed` (which I assume
 is what you're basing `is_rest` on) is one such offender. An `is_rest`
 flag, and an `is_home` exception when `is_rest`, has the selling point of
 internal consistency. This is, in fact, what the new embed features in 4.4
 do (see [34903] and `is_embed`). So, short of a rewrite of how
 `WP_Query::parse_query()` determines context, I guess it's what we should
 do here too.

 > Should is_search be set to true if the s parameter is used in a REST
 request? Similarly, should is_date and others be set based on query
 arguments, as they are now?

 The `is_*` date flags are generally used in templates, which makes them
 irrelevant for REST requests. My inclination would be to let them continue
 to be set, since it's semantically true that, eg, a `wp/v2/post/` request
 containing date params is, in fact, a date request. `is_search` is a bit
 different because `WP_Query` uses it internally to determine fallback
 values for `posts_per_page` and `posts_per_page`. Historically, these
 fallbacks are intended for regular browser requests, so it makes sense
 that you wouldn't want them set in a REST request. Those are my thoughts,
 at least - I'm happy to defer to what your team thinks, since you've
 thought a lot more about use cases.

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