[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
Component:  Posts, Post Types                   |  Release
 Severity:  normal                              |     Version:
 Keywords:  has-patch dev-feedback 2nd-opinion  |  Resolution:
                                                |     Focuses:
------------------------------------------------+--------------------------

Comment (by MikeSchinkel):

 Replying to [comment:66 danieliser]:
 > This one included example code links and an example of what I think
 would be a sufficient filter for the pure context of changing the object
 class returned.
 >
 > https://core.trac.wordpress.org/ticket/12955#comment:52

 While I would be ecstatic to see this ticket moved forward. changing the
 object class would be 3 steps forward and then 2 steps back. It would
 create broken code if any classes are used statefully, e.g. if you assign
 value to properties and expect those values to be retained later in the
 code. It could result in a lot of memory thrashing; creating new objects
 based on existing objects every time a template tag used `get_post()` to
 sanitize a post.  AND, it is not compossible; what if two different
 plugins want to change the post type to their own post custom type? Only
 one plugin would get to win.

 '''As I think about it maybe the answer to this use-case need is not to
 filter get_post and not to remove `final` but instead''' to extend
 `WP_Post` with magic methods and filters.  Add `__call()` `__set()` and
 Add filters that can affect both those as well as `__get()`.  Add an
 action hook in `__construct()` and add a property array `supports` that
 allows plugins to attach support (by array key) to posts and their own
 instances to implement the support.

 This would be much more compossible across plugins and would still allow
 plugins to ''"decorate"'' posts with properties and behaviors.

 This nice aspect of this approach is it might finally provide some
 structured way for 3rd parties to experiment with extensions to posts that
 could later be adopted back into a standardized core, and do it in a way
 that is (mostly) backward compatible.

 If those who objected to this ticket this far (@flixos90, @dd32,
 @boonebgorges) are open to this I could take a stab at implementing what I
 proposed. ''(I actually have
 [https://github.com/wplib/wplib/blob/master/modules/posts/includes/class-
 post-model-base.php a fair amount of experience] with these types of
 architectures already.)''

 '''What do you think?'''

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