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

[WordPress Trac]

#17447: Add 'register_post_type_args' hook
------------------------------------+-----------------------------
 Reporter:  mikeschinkel            |       Owner:  SergeyBiryukov
     Type:  enhancement             |      Status:  reopened
 Priority:  normal                  |   Milestone:  4.4
Component:  Posts, Post Types       |     Version:  3.1
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+-----------------------------

Comment (by MikeSchinkel):

 Replying to [comment:46 wonderboymusic]:
 > > professional programmers often need to modify the behavior based on
 client expectations and requirements
 >
 > Professional programmers offer solutions to clients. Clients don't
 dictate specific modifications to `register_post_type()`.

 Of course not. But sometimes the best and most performant way to offer a
 specific solution would be through this hook acting on builtins.

 > What other things to do you want to change, specifically?

 Listed [above https://core.trac.wordpress.org/ticket/17447#comment:43].

 A big reason to do this is to change values before the values trigger code
 to be run whose results have to be  reverted.  The code that ends up
 getting called that needs to be reverted at time includes calls to
 `add_rewrite_rule()`, `add_permastruct()`  and
 `register_taxonomy_for_object_type()`.  Unraveling those functions after
 the fact, especially the first two, is a PITA and introduces potential
 bugs if you don't get it correct.

 Also, for example, being able to add a property ''(i.e. `'x_newclarity'`
 named with `'x'` for extension and the rest after my company name)'' to
 the post type array that would get passed around with the return value of
 `get_post_type_object()` so we can be sure it is always there.  This would
 allow a developer to add, for example, metadata about generating reports
 for a post type or metadata for columns in the admin or metadata for
 customized export.

 > If your use cases are vague, then they aren't an emergency.

 I would seem an emergency should to be something that would go in +x.x.1
 patches, improvements to the platform to be in +x.1 releases.

 And if we wait, we are likely to have to wait another 4 years more for the
 original purpose of this request to be addressed.

 If tickets for legitimate needs were addressed more frequently, it would
 not be as important to emphasize this request now.

 > There are no plans to officially offer a filter for these args. If you
 want to change the `global` value for `$wp_post_types`, you can, and you'd
 be accomplishing the same thing. You're also voiding your warranty. Want
 to do it as soon as the post type is registered? Use the
 `registered_post_type` action.

 This is a case of ''"It's hard to know how people will leverage it before
 you make it available."''

 Why should you take a stance of ''"no"'' when addressing in core would be
 so trivial and the downside effectively moot?  Asked another way, what
 harm are you trying to avoid?

 > This isn't a "professional" vs "amateur" argument.

 You misinterpreted my statement to emphasize the word _"professional"_; if
 my wording misled you I apologize.  I intended for you to instead focus on
 the word _"client"_ as a use-case in contrast with _"a plugin or theme
 meant for wide distribution."_

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