Make WordPress Core

Opened 5 years ago

Last modified 3 months ago

#12955 new feature request

Add get_post filter

Reported by: JohnLamansky Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: has-patch filter
Focuses: Cc:


This patch filters the return value of the get_post() function. I would find this very helpful for a plugin I'm developing.

Attachments (1)

post.php.diff (687 bytes) - added by JohnLamansky 5 years ago.

Download all attachments as: .zip

Change History (15)

@JohnLamansky5 years ago

comment:1 @scribu5 years ago

  • Keywords has-patch added

comment:2 follow-up: @dd325 years ago

Out of interest, What is the use-case for this exactly?

comment:3 @mikeschinkel5 years ago

  • Cc mikeschinkel@… added

comment:4 in reply to: ↑ 2 @JohnLamansky5 years ago

Replying to dd32:

Out of interest, What is the use-case for this exactly?

I'd like to filter posts retrieved via XMLRPC/APP. Currently, the function chain goes like this: XMLRPC/APP method -> wp_get_single_post() -> get_post() -- None of these functions are filtered. Right now I have to manually override every single XMLRPC/APP method that retrieves posts, which is a pain. I'd love to be able to filter get_post() like this:

if ( defined('XMLRPC_REQUEST') || defined('APP_REQUEST') )
	add_filter( 'get_post', 'my_plugin_function' );

comment:5 @JohnLamansky5 years ago

  • Cc JohnLamansky added
  • Keywords filter added

comment:6 @nacin5 years ago

  • Milestone changed from 3.0 to Future Release

comment:7 @JohnLamansky5 years ago

  • Milestone changed from Future Release to 3.0
  • Summary changed from Filter request for get_post to Add get_post filter

Since this filter would really help me with a plugin I'm developing, I'd really like to have it for 3.0 so I don't have to wait several more months for 3.1, if at all possible.

comment:8 @nacin5 years ago

  • Milestone changed from 3.0 to Future Release

There is technically a workaround available. It's a pain as you say, but I don't want to change this so late in the development cycle.

comment:9 @meqia4 years ago

  • Cc meqia added
  • Type changed from enhancement to feature request

I apologize for my bad english but why you have abandoned the idea of ​​a filter to the function get_post(); ? Because it would be interesting to provide change the values ​​returned. For example when using the function wp_nav_menu() who call get_post();

veuillez m'excuser pour mon mauvais anglais mais pourquoi vous avez abandonné l'idée de mettre un filtre sur la fonction get_post(); ? Car il serait intéressant de pourvoir modifier les valeurs retournées notamment lorsque l'on utilise la fonction wp_nav_menu(); qui appel get_post();

comment:10 @nacin20 months ago

  • Component changed from General to Post Types

comment:11 @MikeSchinkel20 months ago

I could really use this. Any chance this will get considered soon?

comment:12 @nikolov.tmw11 months ago

I second the idea for a filter on get_post(), but I just ran into a possible side effect of the suggested patch.

Having the following super-simple code:

function my_post_filter( $post ) {
	$post->post_title .= ' | Filters are awesome';

	return $post;
add_filter( 'get_post', 'my_post_filter', 10 );

Results in the main post being displayed having it's title become something like this: "Hello world! | Filters are awesome | Filters are awesome | ...".
Now my question is the following - should we leave it up to the developers to make sure they're not filtering the same object multiple times, or should we come-up with an idea of how to avoid having to do that in the first place?

WP_Post::filter() seemed like a good place, but it never seems to run under normal circumstances, since the passed $filter is always the same as $this->filter.

comment:13 @sundquistm6 months ago

I'm also interested in this filter.

Use-case: being able to properly support revisions complete with versioned post-meta and arbitrary data. Unless I'm mistaken, there's no way to fully and properly implement this without being able to filter get_post. The required workaround(s) are very ugly.

Last edited 6 months ago by sundquistm (previous) (diff)

comment:14 @danieliser3 months ago

I support this as well. Use case, attaching extra fields into the post object.

Currently got a working concept for something like a partner table for posts, such as location information. This is useful in itself since querying post meta for radius location searches is very taxing if you have say 50k listings(CPT). A second table to manage these means easily querying using built in MySQL methods for these types of searches.

This patch applies simply because say I have address info in a partner table, I can then join that row to the post object so that $post->city, $post->state etc are available. Currently I am using a wrapper function that simply calls get_post() and then appends the extra keys. But being able to filter these on the initial get_post call would mean one less step. I'm sure there are many other uses for this as well.

Note: See TracTickets for help on using tickets.