[wp-trac] [WordPress Trac] #34875: Allow developers to use an extended version of WP_Post (also WP_Term & WP_Comment)

[WordPress Trac]

#34875: Allow developers to use an extended version of WP_Post (also WP_Term &
WP_Comment)
-------------------------------+-----------------------------
 Reporter:  flixos90           |      Owner:
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:  4.4
 Severity:  normal             |   Keywords:
  Focuses:                     |
-------------------------------+-----------------------------
 A lot of times, developers use their own classes to work with post objects
 (or term or comment objects). In the rest of this ticket, I am only going
 to refer to `WP_Post`, but the other two classes are similar here.

 Right now, using a custom class is only possible by basically wrapping a
 `WP_Post` object with it. If for example a theme does this, it usually
 results in creating an instance of that class in almost every theme
 template file related to posts. It would be a much better development
 workflow to be able to

 * actually extend the `WP_Post` class instead of wrapping it and
 * do it in the `get_post()` function so that it happens everywhere

 So this ticket probably addresses two issues which however are closely
 related to each other. I saw that my first point has already been
 discussed in #24672 a while back. Now that we have `WP_Term` and
 `WP_Comment` in the upcoming 4.4 release, it might be worth reconsidering
 it, as @nacin describes in the ticket.

 If we realize the first point above, we could also consider doing the
 second since this change would actually make the whole thing much more
 useful. If we can used an extended version of `WP_Post`, we could have
 custom classes tailored to the more special needs of certain custom post
 types etc. This would obviously require a deep change in WordPress where
 developers would be able to replace the default `WP_Post` class with their
 own subclass of it. Below you can find a code snippet of how that could
 look like (only has the `get_post()` function, the code in the class
 itself would of course need to be adjusted too):

 {{{#!php
 <?php
 function get_post( $post = null, $output = OBJECT, $filter = 'raw' ) {
         if ( empty( $post ) && isset( $GLOBALS['post'] ) )
                 $post = $GLOBALS['post'];

         $post_class_name = apply_filters( 'wp_post_class_name', 'WP_Post',
 $post );
         if ( 'WP_Post' !== $post_class_name && ( ! class_exists(
 $post_class_name ) || ! is_subclass_of( $post_class_name, 'WP_Post' ) ) )
 {
                 _doing_it_wrong( __FUNCTION__, sprintf( __( 'The class %s
 is not a valid PHP class for a post object.' ), $post_class_name ),
 '4.5.0' );
                 $post_class_name = 'WP_Post';
         }

         if ( $post instanceof WP_Post ) {
                 $_post = $post;
         } elseif ( is_object( $post ) ) {
                 if ( empty( $post->filter ) ) {
                         $_post = sanitize_post( $post, 'raw' );
                         $_post = new $post_class_name( $_post );
                 } elseif ( 'raw' == $post->filter ) {
                         $_post = new $post_class_name( $post );
                 } else {
                         $_post = WP_Post::get_instance( $post->ID );
                 }
         } else {
                 $_post = WP_Post::get_instance( $post );
         }

         if ( ! $_post )
                 return null;

         $_post = $_post->filter( $filter );

         if ( $output == ARRAY_A )
                 return $_post->to_array();
         elseif ( $output == ARRAY_N )
                 return array_values( $_post->to_array() );

         return $_post;
 }
 }}}

 While this is a deep change, I think it would benefit the workflow of a
 lot of developers. Let's discuss.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34875>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform