This article is a follow up to this previous post, which explored a method for adding CMB2 meta to the WP REST API. As CMB2 author Jason Sternberg mentioned in a comment on that post, WP REST API support was in the process of being built in at that time.
Now that time has come.
I just wanted to take a few minutes to cover some questions about the recent update to CMB2 and what’s coming up for WordPress 4.7.
What’s going on with WordPress 4.7?
The WP REST API is a work in progress and is being added to the WordPress core in stages. WordPress 4.4 merged in the main infrastructure, but not the entire project. The infrastructure merge created the base for all calls to the API, and a platform for others to build on. It determines how the JSON is created and creates the ability for the URL scheme in general.
This next chunk will be merged with WordPress 4.7, targeted for release in early December 2016, and will add the first wave of endpoints, known as the content endpoints. As opposed to management endpoints (which will be used to control aspects like settings, plugins, themes), content endpoints refer mostly to your site’s content, like posts, pages, meta, and even users.
Previously, you would have needed to install the WP REST API v2 plugin separately to have full access to these endpoints. After 4.7, that plugin will no longer be necessary (and might even deactivate itself when you update). Future development on the WP REST API may move to another feature plugin.
Beyond 4.7, there are still a few more areas that need to be worked through, including the management endpoints mentioned earlier, but also trickier areas like authentication. In summary, though, with sites running 4.7, you can take advantage of CMB2 and the WP REST API with a lot more confidence and ease.
Is it safe to update CMB2?
As far as I can tell, there are no breaking changes. Everything should continue running as before. Please comment if you see otherwise.
What if I had already added those endpoints manually?
It’s important to note that the method detailed in my original post is still valid for reading the data and will not conflict with this update. The newly added
show_in_rest property defaults to false, but if you’ve added endpoints manually, they’ll still appear as before.
It’s also worth noting that CMB2’s new
show_in_rest property adds the endpoints differently than we added them before, so you cannot remove our old custom
register_rest_field() setup without making sure that you update any code that expects to find those fields in the API.
For example, while we added our fields individually to the post, CMB2 actually groups them and adds them under the name of the meta box which is then under the ‘cmb2’ property. So if you were accessing this data in JS, instead of being able to reference a variable like
post._prefix_email, you’d instead need to reference
Sidenote: This is actually a great thing and probably has something to do with how they gave metaboxes their own wp-api namespace and endpoints. I’d always thought of the ‘box’ part of the metabox as more of a stylistic or aesthetic container, but I’m definitely more curious about how others use them as functional units.
Point is, don’t remove those old manual additions unless you’ve already updated any references to them. If you access that data through those older properties from a mobile app, for example, you’ll probably need to leave those legacy references for a while.
In summary, you can update the plugin, leave code as is, and it’ll still be working. But I’d say that as you move forward, start to incorporate this new built in method for WP REST API support.
There’s a lot more going on under the hood and it looks like they really thought this through as they developed it.
My previous post on CMB2. [briancoords]
Great podcast episode about the REST API. [PostStatus]
CMB2 documentation on the new REST API functionality. [github/webdevstudios]