get_post_statuses() and get_page_statuses() are hardcoded

[rmccue]

Despite the support for registering custom post/page statuses in core, both get_post_statuses() and get_page_statuses() are hardcoded.

Both of these functions are only used in the XML-RPC API in core, however this may affect plugins.

(Somewhat related to the editorial-flow component, although that's on hiatus at the moment.)

[nerrad]

make sure get_post_statuses() includes registered post stati

[sillybean]

Would it make sense to turn these into wrappers for get_post_stati()?

[nerrad]

See patch above. I didn't do the same thing for get_page_statuses() because it looked like from the code that page statuses are supposed to be a different list from post_statuses and currently there is no way to filter the post status by post_type because post type is NOT considered in registering post status.

[nerrad]

Replying to sillybean:

Would it make sense to turn these into wrappers for get_post_stati()?

No, because get_post_stati() return a filtered list of objects. right now get_post_statuses() returns an array indexed in status->name/status->label pairs and any client code using the function would expect the same. I still use the $wp_post_statuses global however, and created a helper function to spit out an array setup in the format using get_post_statuses() currently expects.

[SergeyBiryukov]

Related: #12706 (ticket:12706:17, ticket:12706:48).

[wonderboymusic]

24722.diff​ returns a map of non-internal statuses, but I'm not sure how useful this is. Without being able to associate object types to statuses, this is a very incomplete API.

Trac ticket: #24722