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

 Replying to [comment:22 MikeSchinkel]:
 > '''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.
 >
 > 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.
 >
 > So I am thinking that to extend a `WP_Post` we should use action and
 filter hooks instead of subclassing, and inspecting `'supports'` to be the
 WordPress equivalent of for testing a class for an interface.
 >
 > See my proposal [https://core.trac.wordpress.org/ticket/12955#comment:69
 here].

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

 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.

 @jorbin
 > What happens when a plugin adds a method that returns unescaped data and
 handles the escaping later and later core adds a method with the same name
 where it is returned escaped? A 2nd plugin using that method could
 introduce a security vulnerability since it assumes the data is escaped by
 core.

 Sorry but I don't get this. A second plugin would instantiate \WP_Post,
 not a plugins extension of it - would it not? Without (bad design)
 dependencies between plugins this would never happen. When calling
 \WP_Post methods the return format would always be as expected. Extending
 a class doesn't change the behavior of the core class itself.

 Also it would be a security vulnerability introduced by the plugin, and
 should therefor be handled by the plugin. Wordpress core can not and
 should not raise concerns only because there are bad plugin authors :)

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