[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:68 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.

 I think what may be happening is my use-cases and your use-cases may be
 different, so [https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
 like the blind men and the elephant] we are seeing different aspects of
 the problem.

 The situation I am seeing is when I want to have `global $post` carry
 information and behavior that is beyond what `WP_Post` normally carries,
 and I don't want a `get_post()` to destroy my extra information and
 behavior.

 One approach is to allow `$post` to be a different post type, but another
 approach I am having just recently realized is to allow `WP_Post` to be
 internally extended to carry information and behavior and with this we
 could ultimately end up solving the same problems. Instead of creating a
 child class to extend `WP_Post` ''(where only one child class can be used
 at a time)'', containment would allow `$post` to contain our instance
 classes and use magic method and hooks to delegate behavior to our
 contained instances.

 > But I can tell you my models that extend NAMESPACE_WP_Post classes are
 easily cachable like any WP_Post object would be....

 My argument above said nothing about caching.  Rereading what I wrote I'm
 still not sure what I wrote that would have given that indication.  So I
 think caching is a moot issue here; not the actual concerns I expressed.

 > 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.

 While it might be reasonably slim my opinion is that it would potentially
 happen frequently.  So reasonable people can disagree.

 But I don't think its potential frequency is an important debate point.
 If it can conflict '''at all'''  then I think that would indicate it to
 not be the best course of action. We should always enable compossible
 functionally and provide methods to negate conflicts when they arise such
 as allowing filters to be reordered by an action hook.  OTOH, conflicting
 ''(what are effectively)'' child classes are very difficult if not
 impossible to reconcile.

 > 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.

 That is an interesting approach, and one I could see value for addressing
 a subset of use-cases, but it does not address at least one of the use-
 cases I envision which is a plugin that wants to add information and
 behavior to '''''existing''''' post types but not have other plugins wipe
 out that information and behavior.

 Basically for this use-case I want to be able to effectively add a `Trait`
 to `WP_Post`, but of course do so dynamically.  My guess is that what I am
 proposing would meet your use-cases too, just not in the way you have
 currently implemented them and/or in a way you are currently envisioning
 them.

 For me what is important is to make these types of extensions
 '''''possible'''''; how we make them possible is much less important to me
 as long as we can make them possible.

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