Retrieve post type information in XML-RPC

[maxcutler]

This and the plural version (#18437) should probably include the 'name' field in the returned array. The name may be supplied as a method parameter (or an array key in the plural version), but that forces the API consumer to keep track of it separately. It would be much easier if all the fields were returned in the same struct.

I'm also curious as to how you selected the subset of fields to return. Some that could be useful like 'public', 'export', 'menu_icon' are missing. If you don't want to add them by default, it might be nice to have the list of fields be put through a filter so that plugins can modify what gets returned.

[nacin]

Seems like it should just return get_post_type_object(). That said, some values like 'taxonomies' are only for registration, and I don't think they'd be accurate. (Not positive.) For that you'd need to consult get_object_taxonomies() and also return that value.

[nprasath002]

Returning all the information (using get_post_type_object) is costlier.
The response time of the clients will be huge for slow net connections.
We need to to have a lighter version which returns a subset of fields
and put through a filter so that plugins can extend it.

I will work on a patch and add.

[maxcutler]

Cleaned up the patch formatting and implemented tweaks recommended by nacin, using the prepare_post_type method from #18437.

nprasath002, if you are still concerned about the size of the response, perhaps we can implement a fields parameter like in #18433 and have the default value be a smaller subset. But in any case, plugins can use the xmlrpc_prepare_post_type filter to refine the response.

[markoheijnen]

Created a new patch that combines this ticket with #18437. I also added filter parameter for getPostTypes and fields parameter for both.
I'm not sure how the naming should be. It's most likely it can be better grouped.

[markoheijnen]

New get all theme support function, updated PHPDoc and little changes to _prepare_post_type

[markoheijnen]

wp_getOptions can also returns post thumbnail theme support

[markoheijnen]

After some discussion in the IRC chat on 2 March I decided only to return the theme support for now. That shows if the WordPress installation supports.

For all post type support you can include a new option that includes all post types with thumbnail support like the following code:

$posttype_supports = array();
foreach ( get_post_types() as $post_type ) {
	if ( post_type_supports( $post_type, 'thumbnail' ) ) {
		$posttype_supports[] = $post_type;
	}
}

[westi]

The patch in wp.getPostType.5.patch​ looks good.

It would be nice to have some unit tests before we commit the new functions wp.getPostType and wp.getPostTypes adding the extra "option" seems like a no-brainer.

Would you be able to write some test cases for the new functions?

[westi]

Test case for the featured image option added in ​[UT568].

[westi]

Option added in [20155] props markoheijnen (which I forgot)

[maxcutler]

Refreshed patch with some minor fixes found while writing unit tests in ​[UT587].

[westi]

In [20271]:

XMLRPC: Add new wp.getPostType and wp.getPostTypes apis. See #18436 props maxcutler, markoheijnen and nprasath002.

[maxcutler]

New bugs or enhancements on new tickets.