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

 @jorbin Core should not add a method that returns escaped data...

 Alternately core could follow a naming convention that is likely to not be
 one that a plugin would ever implement unescaped, for example:

 {{{
 $post->the_title_attr()    <-- Sanitizes with esc_attr()
 $post->the_content_html()  <-- Sanitizes with wp_kses_post()
 $post->the_permalink_url() <-- Sanitizes with esc_url()
 }}}

 Basically anything that begins with a `the_` is a template tag and should
 echo escaped values but anything that just returns a value is never
 escaped ''(we have used this convention for many years, and it works
 brilliantly.)''

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

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