Need to be able to register a CPT with REST API support

[bobbingwide]

Referring to http://v2.wp-api.org/extending/custom-content-types/
I extracted the following text.

When registering a custom post type, if you want it to be available via the REST API, you should set, in the arguments passed to register_post_type an argument for show_in_rest. Setting this argument to true will add a route in the wp/v2 namespace, as long as you use the default post controller (see below.)

You can optionally set the rest_base argument to change the base url, which will otherwise default to the post type’s name. In the example below, “books-api” is used as the value of rest_base. This will make the URL for the route wp-json/v2/books-api instead of wp-json/v2/book/ which would have been the default.

In addition, you can pass an argument for rest_controller_class. This class must be a subclass of WP_REST_Controller. By default, WP_REST_Posts_Controller is used as the controller. If you are using a custom controller, then you likely will not be in the wp/v2 namespace.

Requirement

• oik-types should at least support the show_in_rest parameter.
• we also need to support show_in_rest for custom taxonomies.

[bobbingwide]

Alternative... hardcode the solution in plugins where the CPT and custom taxonomies were originally created using oik-types but which would benefit from being registered in real code. e.g. bigram.

This alternative solution only appears to work when the oik-types plugin is deactivated.
There must be something wrong with the way oik-types overrides the programmatically created registration with its version.

[bobbingwide]

There was. It was replacing the definition in the filter function for "register_post_type_args".
So if the previously saved values did not contain all the keys passed to register_post_type() then these values were lost. Merging the arrays seems to fix the problem.

[bobbingwide]

Closing this issue now. As of oik v4.4.0 we also support custom fields in the REST API.