[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:  Awaiting
Component:  Post Types                          |  Review
 Severity:  normal                              |     Version:  3.1
 Keywords:  has-patch dev-feedback 2nd-opinion  |  Resolution:
------------------------------------------------+--------------------------

Comment (by Jesper800):

 Replying to [comment:7 mikeschinkel]:
 > Replying to [comment:6 SergeyBiryukov]:
 > > `registered_post_type` and `registered_taxonomy` were added in
 [18833].
 >
 > Those are great, thanks.
 >
 > But the real reason for my request here is the get hook-based access to
 the args so I'm going to change the title of this ticket and to add the
 patch I'd like to see.
 >
 > This patch would allow a plugin to disable some of the the default
 processing in register_post_type() and replace it with its own.
 I agree: plugin authors need to be able to edit post type arguments on
 registering them. Currently, the only way to do it is by directly
 accessing `$wp_post_types` (come to think of it, `get_post_type_object()`
 should also work), which is not only undesirable but also quite
 inconvenient.

 As far as your diff-file is concerned: the second one seems partially
 right. Naming the filter 'register_post_type_args' complies with the
 standards, and all necessary parameters are passed.

 However... I'm wondering whether or not it would be better to apply the
 filter before calling `wp_parse_args`. That way, you make sure that all
 values required for registering a post type are present. This is different
 from what the standard is for filtering arguments when fetching data, but
 in this case we're actually creating a post type object that has to have
 certain properties, as people (and WordPress) expect them to be there,
 e.g. the post type labels.

 If we call the filter before `wp_parse_args` we make sure that all
 required properties are available.

 Returning `false` on `empty( $args )` is definitely not the way to go, a
 `WP_Error` should be returned in that case.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17447#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software