[wp-trac] [WordPress Trac] #12955: Add get_post filter

[WordPress Trac]

#12955: Add get_post filter
------------------------------------+-----------------------------
 Reporter:  JohnLamansky            |       Owner:
     Type:  feature request         |      Status:  new
 Priority:  normal                  |   Milestone:  Future Release
Component:  Posts, Post Types       |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+-----------------------------

Comment (by boonebgorges):

 I feel very uneasy about a generic 'get_post' filter. The `WP_Post` class
 is nothing more than a caching wrapper for a database query. It doesn't
 validate properties, it doesn't enforce types. Critically, it doesn't
 provide a stable interface that actually defines what a post-ish object
 needs to be able to do. If we want the ability for developers to mock
 post-ish objects without requiring that they be stored in the wp_posts
 table (which I think we do, in the long run), we should (a) decorate
 `WP_Post` and friends with actual getter/setter methods, (b) provide one
 or more `interface`(s) describing the capabilities of post-ish objects,
 and (c) move toward more consistent type hinting and `instanceof` checks
 where post objects are used throughout WP. In this way, we can more
 clearly describe what a "post" __is__, helping us to ensure that core is
 not saddled with undue backward compatibility concerns due to a lax/non-
 existent concept of Posthood, and will make it easier for developers to
 extend WP without guessing at what counts as a "post". Related: #24672

 In any case, I'm inclined not to force the issue just for the sake of
 Customize Posts, especially since (if I understand correctly) the goal is
 to support plugins that use `get_posts()` or `suppress_filters`.  In the
 same way that plugins have to opt in to have selective refresh enabled for
 widgets, it doesn't seem out of line to me that a plugin would have to
 conform to certain standards - like not using `suppress_filters` - to be
 compatible with Customizer editing. Also, you always have the sledgehammer
 available of forcing `suppress_filters` to `false` during a
 `pre_get_posts` callback.

 If we were to consider a 'get_post' filter at this point in time, I think
 it would look more like @sc0ttkclark's suggestion in [comment:22 comment
 22] than like [attachment:12955.5.diff].

 > @sc0ttkclark That change would unfortunately result in not filtering all
 $post instances so it makes it a non-starter.

 Nearly every place where WordPress pulls up a post object, it runs it
 through `get_post()`. And in most of the cases where we call `new
 WP_Post()`, it looks like it's by accident and could easily be changed
 over to a `get_post()` call.

 Moreover, it's a bad idea to filter before the cache. If you store a
 filtered value in the cache - especially one that contains more properties
 than a default `WP_Post` object - how will WP know how to invalidate? If
 we must have a pre-cache filter, it should be along the lines of
 `pre_get_post`, and would skip the cache and database altogether.

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