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

 Replying to [comment:74 danieliser]:
 > That completely defeats the purpose of OOP and extending the base model
 from the limited context available in that ticket. Feels like a workaround
 rather than a real solution.

 OOP is not one thing, and since I first learned of OOP in 1985 OOP best
 practices have evolved significantly.  So I don't think it is helpful to
 appeal to authority here since OOP is not one well-defined authority but
 has been improved over time by people introducing new concepts to address
 the inherent problems in OOP. And one of those problems is single static
 inheritance where the application enables dynamic addition of code (e.g.
 users installing plugins and switching themes.)

 > Final does need to be removed, but the filter part makes no sense once
 you remove final.

 `final` needing to be removed is definitely arguable, as this ticket's
 activity can attest to, and even if `final` were removed I could still see
 valid reasons a developer would want a `get_post` filter.

 Still, that does not address the situation where two plugins substitute
 their own post extensions and then when the two plugins are used together
 the user's site crashes because the last plugin to add their extension
 wiped out the extension that was first added.

 That said, the more I think about it the more I think this concern
 primarily applies to built-in post types and not to custom post types that
 are implemented for a specific plugin or specific site.  Those we should
 be able to extend without too much concern.

 So consider the following proposal:  We added a private "lock" array to
 WP_Post that defaults to all the built-in post types and a method that
 allows checking it a post type is locked.  If a post type is not locked
 them the `get_post` filter would not reset to clean `WP_Post` but if it is
 locked it would trigger an error.

 Then we could also add a method that allows adding post types to the lock
 array so that plugins like WooCommerce could lock their post types when
 loading too.

 ''(We could even disallow locking post types that do not contain an
 underscore, to encourage namespacing.)''

 I think if we had this we could safely add a `get_post` filter for custom
 post types only.  Does anyone else see an issue with this?

 BTW, this new proposal is orthogonal to #43740 and thus in my mind does
 not negate the value of that proposal, specifically for built-in post
 types.

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