[wp-trac] [WordPress Trac] #49644: Move logic from register_post_type() into WP_Post_Type->register()

[WordPress Trac]

#49644: Move logic from register_post_type() into WP_Post_Type->register()
-------------------------------+------------------------------------
 Reporter:  MikeSchinkel       |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:  5.4
 Severity:  normal             |   Keywords:  has-patch dev-feedback
  Focuses:                     |
-------------------------------+------------------------------------
 I have not looked at `register_post_type()` in several years, but was
 pleasantly surprised to find major improvements where most of the logic
 was refactored and moved to `WP_Post_Type`.

 Still though, it appears there are a few missing capabilities that a bit
 more refactoring would resolve.

 I propose we move most of the logic found in `register_post_type()` into
 `WP_Post_Type->register()` and a bit of the validation logic into
 `WP_Post_Type->__construct()` ''(see attached patch.)''

 Similarly, it would make sense to also move the logic in
 `unregister_post_type()` to a `WP_Post_Type->unregister()`.

 One of the benefits of this change is that currently
 `register_post_type()` has validation logic but
 `WP_Post_Type->__construct()` does not so someone can call `new
 WP_Post_Type('this-is-a-far-too-long-post-type-name')` and not get an
 error and allow a too-long post type name to be registered whereas
 `register_post_type('this-is-a-far-too-long-post-type-name')` currently
 throw an error and not let the name through.  With this change, but
 approaches would validate.

 The benefit of adding `WP_Post_Type->register()` and
 `WP_Post_Type->unregister()` is simply that those wanting to use the
 object to create their post types do not need to duplicate the logic in
 `register_post_type()`.  The benefit of this is being able to write code
 like this and leverage PHP's validation of object property names:

 {{{#!php
 <?php
 $post_type = new WP_Post_Type('my_widget');
 $post_type->label = __( 'Widgets', 'my_app' );
 $post_type->public = true;
 $post_type->menu_icon = 'dashicons-admin-generic';
 $post_type->register();
 }}}

 Notice I added a backward-compatible additional parameter to the
 `unregistered_post_type` hook to indicate if the post type existed in
 `$wp_post_types` before the attempt to unregister it.

 AFAICT there will be no backward compatibility or documentation issues
 with this change, so this should be a slam-dunk, right?

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