Make WordPress Core

Opened 19 months ago

Last modified 14 months ago

#54371 new enhancement

Add posts_results-like filters to WP_Query when return fields are ids or id=>parent

Reported by: sc0ttkclark's profile sc0ttkclark Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Query Keywords: has-patch
Focuses: Cc:


The WP_Query class offers no ability to hook into after queries that return posts as IDs or ID => Parent format.

The changes proposed here introduce new filters that offer similar capabilities to the pre-existing posts_results filter which runs in other cases.

This is similar to #41700 and #41678 but the approach is to address this by simply adding two new filters.

To review those other tickets and how they differ to this one:

  • #41700 requests hooking into after all of the logic runs but before the return is made.
  • #41678 requests refactoring the queries so that the individual ids / id=>parent queries can take advantage of all of the other hooks further down the line.
  • The suggestion in this ticket is to hook the same exact way that the existing posts_results filter does without refactoring or introducing new filter naming.

Change History (7)

This ticket was mentioned in PR #1805 on WordPress/wordpress-develop by sc0ttkclark.

19 months ago

  • Keywords has-patch added

This PR introduces two new filters that work exactly like posts_results but work for when fields is "ids" or "id=>parent".

Trac ticket:

This ticket was mentioned in Slack in #core by sc0ttkclark. View the logs.

19 months ago

#3 @davidbaumwald
19 months ago

  • Milestone changed from Awaiting Review to 6.0

#4 @peterwilsoncc
15 months ago

@spacedmonkey if you have any bandwidth, are you able to take a look at this? Both the related tickets Scott mentions in the description are yours.

#5 @spacedmonkey
15 months ago

I think I prefer the approach from #41700 that only adds one filter but it cleaner for it.

What is the benefit of multiple filters here?

#6 @sc0ttkclark
15 months ago

@spacedmonkey In this case, the intention of the two separate filters is to allow the override to set up the posts array dependent upon how it should be. In one case it's a list of ID integers, in another it's a list of simple objects containing only ID and post_parent.

If there was a suitable solution that simplified that based on the expectation of what $this->posts will contain on each return type, I'd love to see what that could be.

#7 @peterwilsoncc
14 months ago

  • Milestone changed from 6.0 to Future Release

I'm a little unsure about the different names too. I do agree that adding the filters does make sense.

As the beta is due this week, I'll remove this off the milestone so the naming things discussion can continue.

Note: See TracTickets for help on using tickets.