Opened 5 years ago
Closed 4 years ago
#50213 closed defect (bug) (fixed)
REST API: Allow queries other than the main query to be `is_home`
Reported by: | dlh | Owned by: | whyisjake |
---|---|---|---|
Milestone: | 5.5 | Priority: | normal |
Severity: | normal | Version: | 4.4 |
Component: | REST API | Keywords: | commit has-patch needs-unit-tests |
Focuses: | Cc: |
Description
[35690] prevented WP_Query
from falling back to is_home
during REST requests.
ticket:34373#comment:2 noted:
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.
And that is the situation I present now :)
My use case is a REST API endpoint that provides data to a mobile application in which some screens mirror the website's frontend.
Within the route callback, it's possible to create a category or singular query using new WP_Query( $args )
and to pass those queries to existing functions that return data based on $query->is_category()
, $query->is_singular()
, etc. But it's currently not possible to reuse existing functions that check $query->is_home()
unless the is_home
property is set by hand. For example:
$query = new \WP_Query(); add_action( 'parse_query', function ( $q ) use ( $query ) { if ( $q === $query ) { $q->is_home = true; } } );
The attached patch proposes to limit the is_home
restriction to the main query, which I think would allow for secondary queries to behave normally while respecting the spirit of [35690].
Attachments (1)
Change History (8)
#2
@
5 years ago
- Keywords commit added
- Milestone changed from Awaiting Review to 5.5
@dlh Thanks as always for the very clear restatement of the problem. I agree with your assessment that 50213.diff respects the spirit of [35690].
#3
@
5 years ago
I have a totally different use case from the one @dlh described above, but which has run into a similar problem. The solution in 50213.diff would work for me too. +1
#4
@
5 years ago
- Keywords needs-unit-tests added
@dlh, this changeset looks great. Can we add a test here to test this conditional?
This makes sense to me from a REST API perspective. Maybe @boonebgorges has some thoughts from a query perspective?