Opened 6 years ago
Closed 6 years ago
#50213 closed defect (bug) (fixed)
REST API: Allow queries other than the main query to be `is_home`
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| 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
@
6 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
@
6 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
@
6 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?