[wp-trac] [WordPress Trac] #36217: WP_Post_Type class

[WordPress Trac]

#36217: WP_Post_Type class
------------------------------------+------------------
 Reporter:  swissspidy              |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  4.6
Component:  Posts, Post Types       |     Version:  2.9
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------

Comment (by boonebgorges):

 Some general thoughts on the approach here and in #36224.

 @flixos90's [attachment:36217.3.diff] suggests that some aspects of post
 type registration shouldn't happen in the constructor method. IMO we
 should take this point further, and do very little of anything in the
 constructor. Off the top of my head, a sensible pattern might look like
 this:

 {{{
 class WP_Post_Type {
     public function __construct( $post_type = '', $args = array() ) {
         if ( $post_type ) {
             $this->set( 'post_type', $post_type );
         }

         if ( $args ) {
             $this->set_props( $args );
         }
     }

     public function set( $prop, $value ) { ... }

     public function set_props( $args ) {
         // parse with defaults, calculate fallback values, then
         foreach ( $args as $key => $value ) {
             $this->set( $key, $value );
         }
     }
 }
 }}}

 So `$foo = new WP_Post_Type( 'foo', $args );` is just shorthand for `$foo
 = new WP_Post_Type( 'foo' ); $foo->set_props( $args );` This structure
 makes it easier to modify a post type/taxonomy after it's been generated,
 and also makes the construction of a bare-bones post type object much more
 lightweight.

 Stuff that is not related to setting fallback props should be handled in
 standalone methods. Eg `public function generate_rewrite_rules()`.

 Then, in place of the monster logic that's currently in
 `register_post_type()` (or `__construct()` in [attachment:36217.3.diff])
 we can have a convenience method like `start()`:

 {{{
 public function start() {
     $this->set_supports();
     $this->generate_rewrite_rules();
     $this->register_meta_boxes();
     $this->init_hooks();
     $this->register_taxonomies();
 }
 }}}

 or whatever we want the method names to be. And `register_post_type()`
 becomes:

 {{{
 $post_type_object = new WP_Post_Type( $post_type, $args );
 $post_type->start();
 }}}

 which is similar to [attachment:36217.3.diff] but without the underscore-
 prefix method names :)

 This kind of structure will be infinitely more testable, more configurable
 by developers, easier to read, etc. What do others think?

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