WordPress REST API and ACF

I’m continuing to work on the plugin I’ve been talking about in my last few posts and have reached the point of front-end display.  The requirements for this project are to have a quick initial page load ( for which I use native PHP) and filtering in place (for which I use the WP REST API) and deep-linking (for which I use a combination of Javascript and custom WP_Query vars). All of which I hope to get to in further posts, but today I want to talk real quick about getting data in and out of the database via multiple methods (n.b. methods as in methodologies, not PHP methods).

Advanced Custom Fields is our de-facto standard for adding custom data to all of our sites.  It’s ease of use, extensibility, and customizability make it hard to beat.  However that doesn’t mean it’s perfect, in the five years we’ve been using it we’ve had to engineer our way around its shortcomings a few times.  Whenever that happens its always fun to look back and go over what the problem was and how we overcame it.  In the past I would discuss these things with other developers at internal meetings or Meetup groups (or sometimes even WordCamps) but even though I had a blog I never wrote anything, but now that I’ve decided to work on my writing skills I can share this process with the world.

That was a long intro to get to what turns out to be a rather short solution. Which all started with this rather cryptic section in the REST API Handbook.

Problem:

The WordPress REST API doesn’t expose meta data by default.  ACF stores all of its data in the postmeta table so we have no way to access it outside of using PHP functions.

Solution:

WordPress core has had a register_meta since version 3.3, but in 4.6 it was overhauled to include (among other things) support for the REST API.  So now all you need to do to expose your ACF data to the REST API is add the line

register_meta( 'post', '<INSERT ACF FIELD NAME HERE>', array( 'show_in_rest' => true ) );

The most confusing part of this snippet is the 'post' parameter, especially since we’re using custom post types.  In this context, post refers to the type of object that the metadata is associated with, other values can be 'comment' or 'user'.  There are some other arguments that you can pass in the last variable, they can all be found on the WordPress Codex entry.  Obviously the most important one in my case is the show_in_rest, but I also debated setting single to true but ended up leaving it with the default value (false) to make it easier to access any repeater fields we may use in the future.

Coda:

Before register_meta was updated in version 4.6, Aires Gonçalves wrote a cool plugin to add ACF fields to the REST API.  It still exists in the Plugin Repository and on Github and I initially used that, but our sysadmins like to keep the number of plugins to a minimum (I know this is a whole ‘nother argument in the WordPress community, but we are still dealing with decisions made above my pay grade by Sharepoint people that worked here long before me).