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

[WordPress Trac]

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

Comment (by danieliser):

 @Mte90 Gotcha, as long as a thorough recap is included of all the
 pros/cons, possible solutions, and any caveats cited here are included for
 reference it could be a good move. I think I misunderstood the premise of
 your proposal, for which I apologize.

 @MikeSchinkel - Ok so to try and make my reply short, I don't disagree,
 and agree on most of what you said. The issue for me is that I don't think
 there is any valid situation where 2 plugins should be loading a custom
 object. Only one plugin registers a custom post type, so only that plugin
 should be loading a custom object.

 So your proposal in that last reply sounds completely viable. As long as
 when I register the popup post type I can assign `PUM_Model_Popup` as the
 `WP_Post` instance to be loaded all is right with the world ;)

 Beyond that, plugins that extend those custom post types should extend
 them the way that the plugin's developer intends. IE My Popup Maker plugin
 has plenty of filters in our `Popup` model, and if they really need they
 can just extend the `PUM_Model_Popup` class and instantiate an instance of
 their own.

 I don't think this needs to be some wildly complex open filter that allows
 any plugin to overload any post type object with its own output. That
 would be archaic and lack overall benefit. I'm glad we are coming to some
 sort of conclusions on what should and should not be possible. That will
 go a long way to getting a solution crafted that suites all uses and
 doesn't break Backward Compatibility :).

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