An official JSON API is being developed for WordPress and if all goes as planned, is slated for inclusion in the upcoming 4.1 release of WordPress. This is obviously great news for both users and developers alike, especially as WordPress is increasingly used as a platform for applications. While still in development, you can utilize this new API now, in plugin form, via its Github repository.
Right from the start, the feature plugin enables a full-fledged API for all of the built-in WordPress core functionality. Retrieving, creating, editing, and deleting posts, pages, and taxonomies right out of the box. This, in and of itself, is incredibly useful.
As we as developers continue to create custom content solutions for the community and for clients alike, I think it’s important that we plan and prepare for the future API use of our creations. Consider the following bare-bones snippet that many would write to deal with a Staff custom post type:
class My_Staff_Post_Type() { public function __construct() { add_action( 'init', array( $this, 'register_post_type' ) ); add_action( 'save_post_staff_member', array( $this, 'save_meta' ) ); } public function register_post_type() { register_post_type( 'staff_member', array( // Post type args here... ) ); } public function save_meta( $post_ID, $post ) { if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) { return; } // Save some meta box data. Nonce and admin-specific logic here. update_post_meta( $post_ID, '_staff_favorite_color', $_POST['favorite_color'] ); } }
This is admittedly an over-simplification of what is needed to properly support a post type, but you get the idea. The part to pay attention to is the
save_meta
method that’s hooked to the
save_post_staff_member
action. Whenever a staff member post is saved, this will trigger and save any meta that the user may have input via a metabox that may or may not be added to the post edit screen. Great! This is a standard model and it has pretty much taken care of saving custom post type meta data since custom post types came into existence.
Pretty soon, once WordPress core as a JSON API by default, we’ll likely want to do more. Thanks to the wonderful development efforts by the folks working on the new API, it is quite easy to extend to support our custom Staff Member post type. We can add URL route and endpoints for retrieving, creating, updating, and deleting Staff Members externally. Doing so is a bit out of scope for this post, but how cool is that?
Let’s say you’re convinced and you want to extend the API to work with your post type. Along the way, you find yourself writing a method for creating a new Staff Member via the API. Eventually you’ll get to the point where you need to save the same meta data that a user saves when creating via the standard admin. As it stands, you’ll likely end up repeating code to save that data on the API side, which isn’t ideal. The two methods might use different validation checks, etc… but at the end of it all, they update the same meta keys with the same data.
With this in mind, I’ve taken to breaking the actual final data validation and saving out into its very own method. Then the two public-facing methods, saving via the admin and saving via the API, can call this method and do the same work using the same code. Here is the above example written with the API in mind:
class My_Staff_Post_Type() { public function __construct() { add_action( 'init', array( $this, 'register_post_type' ) ); add_action( 'save_post_staff_member', array( $this, 'save_admin' ) ); } public function register_post_type() { register_post_type( 'staff_member', array( // Post type args here... ) ); } public function save_admin( $post_ID, $post ) { if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) { return; } // Nonce and admin-specific logic here. $data = array(); $data['ID'] = $post_ID; $data['favorite_color'] = $_POST['favorite_color']; $result = self::save_data( $data ); // Do something with $result. } public static function save_data( $data ) { if ( ! isset( $data['ID'] ) { return new WP_Error( // Some error ); } // Save actual data. Final validation where necessary. if ( ! empty( $data['favorite_color'] ) ) { update_post_meta( $data['ID'], '_staff_favorite_color', $data['favorite_color'] ); } } }
Here, the actual information is saved via the
save_data
method. The
save_admin
method simply validates and sets up the data based on what’s passed via the meta boxes and admin. Then on the API side we would have something like:
class My_Staff_API_Routes() { // Register routes, etc... public function create_staff_member( $data ) { // Check for required data, etc... $result = My_Staff_Post_Type::save_data( $data ); return array( $result ); } }
Notice how this calls the static method from our main post type class. This allows each method to have its own data requirements and validation, but ultimately save the same data the same way.
There is a lot to be expanded on with how best to accept and deal with API data, but this is the base theory we’ve been using to build projects that have the potential to be extended via the API, and I encourage everyone to consider it as well. There may be technically better ways to accomplish the same thing, and please feel free to say so in the comments, but the ultimate goal is to allow for plenty of flexibility in the future as the WordPress API becomes more mainstream.
The post WordPress Development with an API Mindset appeared first on BWD inc..
