WordPress.org

Make WordPress Core

Opened 8 days ago

Last modified 7 days ago

#50213 new defect (bug)

REST API: Allow queries other than the main query to be `is_home`

Reported by: dlh Owned by:
Milestone: 5.5 Priority: normal
Severity: normal Version: 4.4
Component: REST API Keywords: has-patch commit
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)

50213.diff (606 bytes) - added by dlh 8 days ago.

Download all attachments as: .zip

Change History (4)

@dlh
8 days ago

#1 @TimothyBlynJacobs
8 days ago

This makes sense to me from a REST API perspective. Maybe @boonebgorges has some thoughts from a query perspective?

#2 @boonebgorges
8 days 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 @joemcgill
7 days 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

Note: See TracTickets for help on using tickets.