[wp-trac] [WordPress Trac] #24672: Remove final from WP_Post class

[WordPress Trac]

#24672: Remove final from WP_Post class
-------------------------------+------------------------------
 Reporter:  carlalexander      |       Owner:
     Type:  enhancement        |      Status:  reopened
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  3.5
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion        |     Focuses:
-------------------------------+------------------------------

Comment (by Andy Schmidt):

 Replying to [comment:22 MikeSchinkel]:
 > Beyond that if two plugins subclass a `WP_Post` and both plugins want to
 use in the same context — such as in a theme template page — only one of
 them can win.

 I'm not certain that I understand your concern (but that might be due to
 my lack of experience).

 The possibility of an ill-behaved plug-in interfering with another plug-in
 already exists today with the "posts_pre_query" hook, and always does so
 in many other hooks.

 Specifically, if the first plug-in decides it needs to populate the $posts
 array with WP_Post instances - and the next plug-in simply assumes to be
 the "only one" and  DISCARDS the existing array and returns a hard-coded
 "null", or substitutes its own array - then it doesn't matter if the so
 discarded post instances had been created by the native WP_Post class or
 any subclass thereof?

 Being able to properly sub-class WP_Post does not alter the potential of a
 conflict?

 > '''That said''', I am more and more concerned about my prior advocacy
 for this.  It only works to subclass WP_Post when there can be only one,
 e.g. that the code is in the theme or specific to a site.

 If at any given time a plug-in or theme decides to hook into
 "posts_pre_query" and conditionally instantiate its own WP_Post subclass
 to emulate external data as "posts", or to handle a certain Custom-Post-
 Type, then it would do so after narrowly defining the case in which this
 occurs.

 That wouldn't prevent a different plug-in to equally focus on its
 particular type of posts before creating its specialized WP_Post subclass.

 Once the different instances have been created by their respective plug-
 ins, the only thing that matters is that they will be recognized as
 "instance of" WP_Post throughout the subsequent core code. This way method
 calls and property references by the core will continue to function
 throughout the subsequent code like as if they were instances of the
 native WP_Post class.

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