Fixes #5102

@lezama How do I test this PR?

@lezama Would you mind updating the PR description so we have a better idea of what exactly this PR does? From what I can tell, we're wanting to only sync public post types and ones that are shown in the API or UI. But, perhaps there are some other things I missed?

The expected changes from this pull request are:

• The GET /sites/%s/post-types endpoint now returns two new properties for each post type: show_ui and publicly_queryable
• Post types which have registered including the new (as of WordPress 4.7) show_in_rest flag will use that flag in determining whether a post type is allowed to be administered from the REST API
• Post types which are otherwise publicly queryable (publicly_queryable in register_post_type, falling back to public) are also allowed to be administered from the REST API

By "administered from the REST API", I mean listed, created, deleted, etc.

The last of these bullet points is rather controversial as I see it, but is also most enabling for UIs to build on the REST API. It now opts in many more post types without explicitly being whitelisted merely by being public (previously requiring filter). public is false by default, so it would take a conscious decision on a plugin author's part.

I'm getting this notice when testing:

[04-Jan-2017 23:28:31 UTC] PHP Notice:  Undefined property: WP_Post_Type::$show_in_ui in .../wp-content/plugins/jetpack/json-endpoints/class.wpcom-json-api-list-post-types-endpoint.php on line 60

@ebinnion Good find. Looks like it should be show_ui:

https://codex.wordpress.org/Function_Reference/register_post_type#show_ui
https://codex.wordpress.org/Function_Reference/get_post_type_object

Here are my results of testing with a CPT and a few variations:

With public set, this did show up in the API as expected.

function wporg_custom_post_type()
{
	register_post_type('wporg_product',
		[
			'labels'      => [
				'name'          => __('Products'),
				'singular_name' => __('Product'),
			],
			'public' => true,
			'has_archive' => true,
		]
	);
}
add_action('init', 'wporg_custom_post_type');

When public is false and show_in_rest is true, the new CPT doesn't show up.

function wporg_custom_post_type()
{
	register_post_type('wporg_product',
		[
			'labels'      => [
				'name'          => __('Products'),
				'singular_name' => __('Product'),
			],
			'has_archive' => true,
			'show_in_rest' => true,
		]
	);
}
add_action('init', 'wporg_custom_post_type');

When public is false and publicly_queryable is true, the new CPT doesn't get returned in the API request.

function wporg_custom_post_type()
{
	register_post_type('wporg_product',
		[
			'labels'      => [
				'name'          => __('Products'),
				'singular_name' => __('Product'),
			],
			'has_archive' => true,
			'publicly_queryable' => true,
		]
	);
}
add_action('init', 'wporg_custom_post_type');

Thanks for testing @ebinnion! just addressed your feedback.

With the latest changes, this tests well for me now. I used the code examples from my last comment, and the product CPT showed up when the CPT had public, publicly_queryable, or show_in_rest set to true, as expected. 👍

I did notice that revisions were showing, even though they aren't publicly_queryable. But, it looks like we whitelist that CPT to be in the API here, so all looks good.

🚢

@ebinnion, @aduth I am worried about the refactoring to is_post_type_allowed changing the behaviour of other post related endpoints. What do you think?

I did a quick pass through the API where I saw is_post_type_allowed() and nothign stuck out to me.

We should probably rebase this against master before merging since the PR was started in early November.

Update: I went ahead and rebased.

merged to 4.5 fc6aa76