Using WordPress XML-RPC With PHP: Introduction To The Post Model

Part 3 in a series on working with the WordPress XML-RPC API with PHP.

To being coding our PHP-based solution for working with the WordPress XML-RPC API, we first need to create models for each of the kinds of data we’re going to leverage. The logical place to begin doing that is with posts, since most content in a typical WordPress install are posts.

A model in this context basically means creating a class. (If you’re not familiar with classes, see this primer.)

The class will bring together not only the post fields that we can manipulate through XML-RPC — some of which are complex — but also the methods (aka functions) that will allow us to easily modify the data in those post fields. This will include methods that prepare our data for sending to XML-RPC, and interpret the responses we get back from the API.

That’s what makes a data model: The data itself, or properties / post fields, and the means to manipulate that data via methods / functions.

Why bother with a model?

The Trouble With XML-RPC And Procedural Code

The XML-RPC documentation describes a post in ways that are a bit confusing to novices, and can even be a little daunting to those who are used to using the wp_insert_post function to build posts dynamically.

In short, WordPress’s built-in functions ease a number of complicated relationships, especially surrounding taxonomy, by isolating certain properties of a post, and providing a number of helper functions to assist us in, say, getting the correct term id to provide as a category.

Theoretically, we can do the same using traditional, procedural PHP with XML-RPC. But we have to do so with a number of extra steps, and what we get back from XML-RPC usually isn’t formatted in convenient ways. If we write procedural code, it’s going to be very easy to lose track of which variables we need to set, how those variables should be structured, and which code is setting the final values for those variables; it’s not going to be as tidy as calling a handful of preassigned functions.

My intent at this point was to compare the procedural code for creating a post with wp_insert_post and an XML-RPC call to wp.newPost, but it was so tedious and distracting, I opted against it. Just take my word for it: Procedural code for wp.newPost is a confusing mess that bears only cursory resemblance to using wp_insert_post.

An Ounce Of Preparation Vs. A Ton Of Code

Thankfully, our model will fix that. By first defining in clear terms what a post looks like when working with XML-RPC, and then creating the means to put the right data in the right places, we’ll have a jumping off point for vastly simplifying calls to the XML-RPC API.

Because a post is the backbone of WordPress content, it’s got a lot of properties, including what can be complicated relationships with taxonomy (categories and tags), as well as media. So I’ll break up the discussion of the properties and methods in our model / class over two future posts.

All links in this post on delicious:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Check out the Commenting Guidelines before commenting, please!
  • Want to share code? Please put it into a GitHub Gist, CodePen or pastebin and link to that in your comment.
  • Just have a line or two of markup? Wrap them in an appropriate SyntaxHighlighter Evolved shortcode for your programming language, please!