Add a "get_post" filter to get_post()

[mikeschinkel]

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.

[Denis-de-Bernardy]

You can use the_posts and the_post in the meanwhile.

[mikeschinkel]

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

[davidmosterd]

+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.

[davidmosterd]

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

[davidmosterd]

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

[davidmosterd]

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.

[wonderboymusic]

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

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

[MikeSchinkel]

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.

[chriscct7]

There has been no interest or activity in two years. Closing as wontfix.