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

 Replying to [comment:23 hawaiipersson]:
 > If a plugin where to enforce the use of its class directly in a theme
 that would be a question of bad plugin design, rather than a weakness for
 the extendability in itself.

 I don't understand what you are trying to say here.  If a plugin
 subclasses `WP_Post` how would it use it in theme templates in without
 conflicting with another plugin that used the same approach?   IOW, what
 is your use-case for a subclass?

 > In my opinion plugin authors should never introduce code in the theme
 that would break the site it the plugin fails or is deactivated. In fact,
 the high use of custom functions from plugins called in themes is one of
 the biggest problems with Wordpress today, in my opinion.

 You are thinking of only selected scenarios and selected use-case.  Please
 understand there are other scenarios and use-cases than the ones you are
 focused on.

 There are very valid scenarios and use-cases where code in the theme
 should be dependent upon a plugin. Those scenarios are custom
 ''"applications"'' where themes are developed specifically for a
 ''"(typically vertical market) application"'' plugin, and complex sites
 with a lot of custom functionality.  And in post cases the plugin should
 be a must-use plugin so deactivation is not possible ''(btw, I don't
 understand the concept of a plugin "failing"; sounds like a plugin with a
 bug to me.)''

 In other words when sites are developed and deployed by professional
 developers and sysadmins vs. by end users then intertwining themes and
 plugins is not a concern.

 > Plugins should be encouraged to only introduce content modifications
 through filters and action hooks. With other words, even though I
 understand your concern, I do not believe that this should be dealt with
 by Wordpress core.

 This is where I am especially confused. You say people ''"should be
 encouraged to only introduce content modifications through filters and
 action hooks"'' but then when I suggest adding filters and action hooks to
 WP_Post you argue that ''"this should not be dealt with by Wordpress
 core?"''  Your two statements seem to contradict each other?

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