[wp-trac] [WordPress Trac] #17447: Add 'register_post_type_args' hook

[WordPress Trac]

#17447: Add 'register_post_type_args' hook
-------------------------------------------------+-------------------------
 Reporter:  mikeschinkel                         |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Posts, Post Types                    |  Release
 Severity:  normal                               |     Version:  3.1
 Keywords:  has-patch dev-feedback 2nd-opinion   |  Resolution:
  needs-docs                                     |     Focuses:
-------------------------------------------------+-------------------------

Comment (by engelen):

 Sorry about the patch overload, it took me some to realize I hadn't
 committed my latest changes.

 I would argue that the coarse-grained approach is desirable here. It gives
 developers full control over registered post types, and prevents a huge
 amount of filters being added. My most important argument, however, is
 that there are no post type arguments that ''should'' be usable by
 `register_post_type` but ''should not'' be modifiable by other plugins.

 I've added a patch (a few, actually) that implements this: `register-post-
 type-args-filter.17447.v3.diff`. It implements the filter
 `register_post_type_args`, which filters the post type arguments.

 1. It applies the filter ''before'' calling `wp_parse_args`, which
 prevents removing required arguments via the filter.
 2. The post type name is sanitized earlier on and passed to the filter as
 the second argument.
 3. The filter is only applied to non-built-in post types (i.e. custom post
 types, post types with an `_builtin` false).

 As far as post type labels are concerned: these are already filterable in
 `register_post_type`, as it calls `get_post_type_labels` which has been
 filterable (`post_type_labels_{$post_type}`) since 3.5.

 @MikeSchinkel
 I don't think the post type name should be filterable. The post type name
 is the unique identifier of a post type, which means changing it
 effectively means registering an altogether different post type.
 Furthermore, I don't see a problem with bypassing built-in post types
 altogether at this point, as it's just too fragile. Core and many plugins
 rely on the default, unfiltered settings from the default post types.
 Changing capabilities for these post types, for example, would break a lot
 of sites.

 At this point, I think we should move ahead with adding this to core, as
 this is just about as lean and safe as it will get without losing control
 over custom post types.

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