Allow the post_format taxonomy to be displayed #1448

The post_format taxonomy was shown, until #1279 changed how we determined which taxonomies to show.

When doing taxonomies, I had presumed the post-format taxonomy would not be exposed as such. I've always thought the use of a taxonomy is more of an internal thing rather than an interface. Similar to how we don't show nav_menus as posts.

That was my initial thought anyway. From what I understand, one is not meant to add / remove terms from the taxonomy, so I don't know if that would have to be communicated in the API somehow.

I've always thought the use of a taxonomy is more of an internal thing rather than an interface.

👍 However, this is one of those things it would be nice to get an official core opinion on.

This was brought up originally by @danielpunkass via Slack: https://wordpress.slack.com/archives/core-restapi/p1438229102002621 He noticed that we didn't provide an endpoint for post_format like the XMLRPC API does.

I also noticed that the Post _links include post_format because this line wasn't changed: https://github.com/WP-API/WP-API/blob/develop/lib/endpoints/class-wp-rest-posts-controller.php#L1153

We are inconsistent here.

Thanks for opening the ticket, @rachelbaker. As far as this taxonomy being fairly fixed, I think that is true, however one of the points of the pertinent method in the XMLRPC API is it can be used not only to get a list of terms for the post formats but also to obtain the localized names and, somewhat importantly, whether the current theme makes meaningful use of a given format. For example this would allow a client app to limit the options presented to a user for post format in a similar way to how the WordPress wp-admin editor limits to formats that the current theme supports.

Speaking of localization, though, it raises an interesting question in my mind for clients of the API: should the blog's localization be used to present user-facing strings, or should the client app/service's API be conveyed to the API in order to get localized terms that work in the context of the client's UI? For example MarsEdit is not currently localized so any user running MarsEdit will be viewing an all-English UI. If I ask WordPress for the list of post formats, I should probably be able to specify what localization I want, not just rely on it giving me the terms localized to the language of the blog itself.

This is probably a separate issue and maybe I should open a separate ticket, but in general I think API methods that yield localized terms should support a mechanism for overriding the localization code that should be used for the localization. This is probably a bit of an architectural challenge given the way I think WordPress currently handles localizations.

We should definitely avoid exposing post_format wherever possible; it's definitely an implementation detail. Unlike other taxonomies, you're not meant to add new terms or change any of the existing ones, there's no UI for managing them, and the slugs are all post-format-x with get_post_format using a string replace on that.

We should hide post_format from everywhere, and make it a format field with an enum. We can expose which are available in the current theme through the schema, but it shouldn't use the taxonomy/terms API.