[wp-trac] [WordPress Trac] #63500: Add a filter hook to get_post() to allow modification of the returned WP_Post object

[WordPress Trac]

#63500: Add a filter hook to get_post() to allow modification of the returned
WP_Post object
-------------------------------+------------------------
 Reporter:  mamunur105         |       Owner:  (none)
     Type:  enhancement        |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:  duplicate
 Keywords:                     |     Focuses:
-------------------------------+------------------------
Changes (by dd32):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  General => Posts, Post Types
 * milestone:  Awaiting Review =>


Old description:

> The `get_post()` function in `wp-includes/post.php` is a widely used core
> function that returns a `WP_Post` object from a post ID or object.
> However, it currently offers no way to filter or modify the returned post
> object before it's used elsewhere.
>
> This limits the flexibility for plugin and theme developers who may need
> to customize or inject data into post objects globally — for example, to:
> - Dynamically alter post titles or content
> - Add computed or cached meta fields
> - Modify fields based on user roles or context
>
> ### Suggestion:
>
> Add a filter hook before the return statement in `get_post()`, like so:
>
> ```php
> $_post = apply_filters( 'get_post_object', $_post, $_post->ID );
>

>

> Proposed location:
>
> Just before the final return $_post; line inside get_post() in wp-
> includes/post.php.
>

> Sometimes developers need to virtually adjust or override post data
> without modifying the database.
>
> A common example is: if( 'product' === get_post_type( $id ) )
>
> This condition is hard-coded and relies on the actual stored post type.
> However, there are valid use cases where a developer might want to treat
> a post as a different post type or override a field programmatically —
> for testing, compatibility layers, dynamic translations, or headless API
> adjustments.

New description:

 The `get_post()` function in `wp-includes/post.php` is a widely used core
 function that returns a `WP_Post` object from a post ID or object.
 However, it currently offers no way to filter or modify the returned post
 object before it's used elsewhere.

 This limits the flexibility for plugin and theme developers who may need
 to customize or inject data into post objects globally — for example, to:
 - Dynamically alter post titles or content
 - Add computed or cached meta fields
 - Modify fields based on user roles or context

 ### Suggestion:

 Add a filter hook before the return statement in `get_post()`, like so:

 {{{#!php
 $_post = apply_filters( 'get_post_object', $_post, $_post->ID );
 }}}



 Proposed location:

 Just before the final return $_post; line inside get_post() in wp-
 includes/post.php.


 Sometimes developers need to virtually adjust or override post data
 without modifying the database.

 A common example is: if( 'product' === get_post_type( $id ) )

 This condition is hard-coded and relies on the actual stored post type.
 However, there are valid use cases where a developer might want to treat a
 post as a different post type or override a field programmatically — for
 testing, compatibility layers, dynamic translations, or headless API
 adjustments.

--

Comment:

 Hi @mamunur105,

 This request is being tracked in #12955

 Note: Use of WP_Post fields directly is discouraged and the helper methods
 should be used instead, additionally, only modifying the contents of the
 WP_Post may not reflect through other helper methods.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63500#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform