Make WordPress Core

Opened 3 years ago

Last modified 2 years 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.

3 years 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.

3 years ago

#3 @davidbaumwald
3 years ago

  • Milestone changed from Awaiting Review to 6.0

#4 @peterwilsoncc
2 years 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
2 years 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
2 years 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
2 years 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.