[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 danieliser):

 @MikeSchinkel - Isn't that simply sidestepping the issue? We can already
 wrap queries with our own functions to return custom objects rather than
 posts in half the code it would take to do it your way if I got the
 example codes relation to your proposal. I may have completely
 misunderstood, in which case ignore that.

 But I can tell you my models that extend NAMESPACE_WP_Post classes are
 easily cachable like any WP_Post object would be. Our internal query
 wrappers & object instance/__construct methods do similar automagic on
 loading a cached object that core does. Don't see why core couldn't simply
 cache a new group based on the class name passed for object return.


 Lastly I definitely agree the proposed solution was thin. But I think that
 any situation where plugin A & plugin B would collide would be reasonably
 slim. To clarify plugin A adds custom_type1 and plugin b adds
 custom_type2. Each would have their own object model, and each wouldn't
 replace the others in any sane scenario. If you are implying plugin C
 extends plugin A, then its plugin As job to properly add hooks and filters
 throughout their own object models to handle that, and since they are a
 parent => child relationship this wouldn't really be a reasonable
 collision.


 In my current implementation the model automatically checks to see if the
 post passed in has a valid post type matching what the model requires. If
 not it returns WP_Post.

 Maybe the fully fleshed out solution is to let the object model be defined
 in register_post_type itself, so that there can be only one. Then simply
 have all internal query methods returning WP_Post objects, check the post
 type args and if there is a custom model defined & the models class
 exists, cache that object rather than WP_Post in internal caches as well.

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