WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 8 months ago

#14958 new enhancement

Add a "get_post" filter to get_post()

Reported by: mikeschinkel Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Query Keywords: has-patch close
Focuses: Cc:

Description

I'm finding a need for a plugin of mine to generically annotate a post with additional information when loaded via get_post(). It would be nice if there were a filter just before the end where the post is still in object form.

Attachments (1)

post.php.diff (387 bytes) - added by davidmosterd 17 months ago.
Adds filter 'get_post' to the get_post() function.

Download all attachments as: .zip

Change History (10)

comment:1 mikeschinkel4 years ago

  • Cc mikeschinkel@… added

comment:2 follow-up: Denis-de-Bernardy4 years ago

You can use the_posts and the_post in the meanwhile.

comment:3 in reply to: ↑ 2 mikeschinkel4 years ago

  • Cc mikeschinkel@… removed

Replying to Denis-de-Bernardy:

You can use the_posts and the_post in the meanwhile.

Thanks. OTOH, you are aware that 'the_post' is called by setup_postdata($post) which is not relevant in the use-case that caused me to need this. FWIW, I was wanted to add in the addition values so that when so that when a wp_insert_post_data() was later called the post would have everything needed to save correctly. So I was not needed anything related to the loop here.

-Mike

comment:4 nacin3 years ago

  • Keywords needs-patch 2nd-opinion added
  • Milestone changed from Awaiting Review to Future Release

comment:5 davidmosterd17 months ago

+1

As an alternative use WP_Query instead of the direct select query in WP_Post?
I suppose it might be a performance issue, I don't know. But it would allow the use the filters and actions from WP_Query.

davidmosterd17 months ago

Adds filter 'get_post' to the get_post() function.

comment:6 davidmosterd17 months ago

  • Keywords has-patch dev-feedback added; needs-patch removed

I added a patch. How do you feel on the location and name of the filter?

comment:7 davidmosterd17 months ago

Maybe add the parameters of get_post to the filter might not be a bad idea? It might matter what was supplied to get_post() for the ones using this filter.

comment:8 follow-up: wonderboymusic9 months ago

  • Keywords close added; 2nd-opinion dev-feedback removed

get_post() returns a WP_Post instance - you can decorate that.

$post = get_post( $id );
$post->extra = 'sauce';

comment:9 in reply to: ↑ 8 MikeSchinkel8 months ago

Replying to wonderboymusic:

get_post() returns a WP_Post instance - you can decorate that.

$post = get_post( $id );
$post->extra = 'sauce';

Unfortunately that solution does not address the use-case for which I posted this ticket. Further, it being a WP_Post isn't relevant to the proposed solution because you could have done exactly the same before when it was an stdClass object.

The goal of the ticket was to gain the ability to ensure that all posts that were retrieved for a selected post type had been decorated with other items, i.e. custom fields, child posts, etc. It could also be a method for instrumentation or anything else you'd want to do to ensure that all posts objects created WordPress' code, by other plugin's code or by themes have the properties desired.

However, since the 3 years that have passed as this ticket languished the inclusion of WP_Post actually provides a better location for the hook to address the desired use-case, i.e. in the constructor of WP_Post. Given that it does makes sense to close this ticket but not for the reasons you mentioned but because a new ticket is more relevant; an 'instantiated_post' hook.

Note: See TracTickets for help on using tickets.