REST API: Post Types Endpoint and `public`

[timmydcrawford]

While doing some testing of the /types endpoint, I came across a difference between the new WP REST API endpoint and the WordPress.com API. In the WordPress.com API, the call to get_post_types passes array( 'public' =>true ) as an argument ( ​https://github.com/Automattic/jetpack/blob/master/json-endpoints/class.wpcom-json-api-list-post-types-endpoint.php#L42 ) - while in WP_REST_Post_Types_Controller#get_items() the public attribute is not used.

I chatted with @jnylen0 a bit about this, and we both agree that the current implementation aligns well with show_in_rest, but I figured it would still be worthwhile to open an issue to discuss. A few options we discussed around this were:

Option 1:
Add support, or I suppose "backwards compatibility" for public in the post types endpoint and only return non-public post types when context=edit

Option 2:
Always use array( 'public' =>true ) when grabbing the post types in the endpoint. This feels too restrictive, but it is the route taken in the WordPress.com API

Option 3:
Let it be. show_in_rest means exactly as the name implies.

[MaximeCulea]

Hi @timmydcrawford,
You totally right and to answer the question I rather use array( 'show_in_rest' => false|true ) !

[rachelbaker]

@timmydcrawford The problem with using an existing property, like public, is that when themes or plugin developers registered their post_type following the documentation (​https://developer.wordpress.org/reference/functions/register_post_type/#parameters) they had no way of knowing the full implications of their selected true|false value. This is especially true of any post_type that was registered before December 2016.
This is even more complex when you look at a property like public which has implications for both the front-end and back-end of a site. I can set public to true as a lazy way of setting show_ui and show_in_menu to true and then explicitly set publicly_queryable to false and exclude_from_search to false. #WordPress :( I am surprised the WordPress.com API chose this approach, but always being behind authentication allows for more reckless behavior.

Our challenge was how can we allow make sure existing sites/themes/plugins AND new sites/themes/plugins intend to expose data in the public API. We decided to add the show_in_rest property to the WP_Post_Type object so there would be no confusion. If you set show_in_rest to true, then the post_type is available from the /types endpoint and we register the post type endpoints (based on the rest_base property) for you.

My vote is for option 3.

Option 3:
Let it be. show_in_rest means exactly as the name implies.

[rmccue]

I agree with @rachelbaker; closing as wontfix.