Add 'register_post_type_args' hook

[mikeschinkel]

I have two different use cases where I ideally would be able to hook the register_post_type() function:

1. To add custom attributes and custom 'supports' values; current hooks don't allow adding support at the right time to be fully robust.

2. To disable the default rewrite logic in order to support customized rewrite logic passed as custom attributes.

I've attached a patch that adds 'pre_register_post_type' and 'register_post_type' hooks to register_post_type().

Adds 'pre_register_post_type' and 'register_post_type' hooks to register_post_type().

current hooks don't allow adding support at the right time to be fully robust.

Could you describe that in more detail? In other words, what's wrong with add_post_type_support() ?

Replying to scribu:

what's wrong with add_post_type_support() ?

Red-faced, didn't know about add_post_type_support().

However, that function doesn't allow someone to intercept all $args passed to register_post_type() and change some of them before the register_post_type() operates on the $args. One example would be to set $args->rewrite = false; for all post types using a pre_register_post_type hook, and then define the rewrites differently using the register_post_type hook; this is exactly something I need right now for a project I'm working on.

A plugin developer may want to provide alternate rules for post type archives so it might want to set $args->has_archive = false; using a pre_register_post_type hook, and then define the post type archives differently using the register_post_type hook. This is also something I need.

In addition a plugin developer may want to provide an admin console option that allows the end user to define all the visibility settings for the different post types; a pre_register_post_type hook would enable that.

Another example is$args->columns which would include a keyed array of headers and callbacks and/or $args->column_headers containing an array of headers and $args->column_callbacks containing an array of callbacks. And yet another example would be to add $args->meta_boxes which would include a keyed array of meta_box args.

As stated, some of those examples are ones I currently would like to be able to streamline by specifying in the register_post_type() call making it easier to define a full-features custom post type, and some of these examples of trying to keep WordPress from doing work to create data that is simply going to be thrown away.

I'm bumping into the need for this again, and would love to get this reviewed? Please?

Bumping again? Please? I could really, really use this in 3.5...

I thought we had these already. Must have gotten added elsewhere:

do_action( 'registered_post_type', $post_type, $args );

registered_post_type and registered_taxonomy were added in [18833].

Replying to 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.

#22818 was marked as a duplicate.

Replying to mikeschinkel:

Replying to 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.