At this point, we’ve covered how to create the entities within the plugin (which, as we’ve said, is just a fancy word for another concrete idea). Namely, we’ve got a user and a custom post type, or a book. And here’s where we start to take the two separate entities and combine and work with what we’ll call WordPress metadata association.

But before doing so, it’s important to understand the two types of metadata with which we’ll be working and the two ways (or three ways, depending on how you look at it) in how we can associate the metadata.

As with the rest of the posts in the series, this isn’t meant to be a deep-dive into understanding each of the tables or a deep-dive into each of API functions. Instead, we’re going to survey what’s available, put them to use, and leave finer details for future posts (or perhaps discussions in the comments).

WordPress Metadata Association

Metadata is not exclusive to WordPress. You probably know this. And it’s often defined as:

Information about information or data about data.

And that’s a good way to put it. WordPress offers some different database tables that we can use to provide information about certain other types of entities within WordPress. We’re going to be using a couple of these later in this post, but suffice it to say that WordPress offers:

  • comment metadata,
  • post metadata,
  • term metadata,
  • and user metadata

And all of this is available out-of-the-box.

WordPress Metadata Association

One of the WordPress metadata tables.

The APIs for each of these are consistent, which is nice, too. But, again, we’re only going to be concerned with a couple of these for the remainder of this post.

1. The Metadata Tables

For our example, we’re going to be using one, or both, of the following two tables:

  1. wp_postmeta
  2. wp_usermeta

Granted, in your installation, they may have a different prefix, but the suffix is the same, and you get the idea.

Secondly, we’ll be using the related API functions for associating our metadata. We’ll look at these in code when we’re associating the data between our user and the custom post type (or our author and our books if you want to use the more accurate terminology).

Okay, then. This whole first part of the post is just laying some groundwork for what parts of the underlying WordPress infrastructure we’re going to be using. With all of that said, let’s look at how we can programmatically turn this thing into something a bit more useful.

2. Associating Metadata

The idea behind WordPress metadata association sounds more complicated than it is. Think of it this way:

  • Given two tables, how can we share information between two entities that let one know about the other?

For example, given a user, how can we let the user metadata know about post metadata. Or, turning it around, how can we let post metadata know anything about related user metadata?

WordPress Metadata Association: The Entities

At a high-level, this is really what we’re doing: We’re letting one entity know the other exists and we’re relating it to the other. Or it could go the other way. Depending on your implementation, one may be more beneficial than the other.

1. One-Way

When we talk about creating one-way WordPress associations, we’re usually talking about the idea that only one entity is aware of the other. This means that the user may only be aware of the post.

So we could set up after a post is created such as the user in question is aware of the post that was just created:

Or perhaps it means that the post is aware of the user:

But no matter how you look at it, the association only goes one way.

And though the relationship goes one way, it doesn’t have to be that way. That is, both entities can be aware of one another.

2. Two-Way

Since the metadata APIs are so easy, and consistent, to work with, it’s not hard to work with them. Each of the usually requires at least two of the following:

  1. an ID of sorts to which the metadata is related,
  2. a meta key that can be used to look up the information,
  3. a value that stores information associated with the ID and the post.

Regarding which ID and which key you choose often depends on your implementation, as we’ve seen.

Up to this point, we’ve looked at seeing how to create a one-way association. A two-way association isn’t anything different. It’s just rather than making one entity aware of the other, we make both entities aware of the other:

But this isn’t a decision that should be made just for the sake of it. Instead, it’s worth thinking through some of the reason why you may want to choose one or the other.

Thinking Through The Problem

When it comes to solving problems like this, there isn’t a definitive solution in terms of “you should definitive to it [this way]” whatever way that may be. Instead, you have to ask yourself questions like “what makes for the easiest way to manage this data?”

For example, if you’re primarily interested in user management, then maybe all you need is to have user metadata aware of whatever entity to which it’s related. This way, when the user is deleted, you also make sure to look up the entities related to it via the user metadata table and delete them as well.

Similarly, perhaps the same functionality would go both ways. That is, just as you want to make sure that when a user is deleted, his or her posts are also deleted, you may also want the user deleted (or modified) whenever one of his/her posts is removed. And if that’s the case, then the two-way association allows for that.

Since you have the ID of a given post and the ID of a given user as well as the meta keys you’ve specified, nearly any type of query that you can image either through the WordPress metadata API or WP_Query or even through WP_User_Query is possible.

The End

Ultimately, I hope this series has provided some insight on how to not only create WordPress metadata associations but also how to think abstractly about concepts within WordPress as it relates to creating higher-level implementations in your plugins and your web applications.

For those who are interested, I’m considering releasing this series as a small resource in PDF format along with a functioning plugin to study. If this is something that you’re interested in doing, then please sign up for the mailing list here, and I’ll be sure to let you know when it’s ready; otherwise, use the information in the series to move forward and create something worth

Want More?

Series Posts

  1. WordPress Metadata Association: How To Do It
  2. Programmatically Creating WordPress Users
  3. WordPress Post Types: An Abstraction For Entities
  4. WordPress Metadata Association: Relating Entities



Join the conversation! 6 Comments

  1. Heck, I though WordPress MetaData Association was a new org.

  2. Well for that sort of stuff i like to use deals with it and stuff around CPT nicely and is one of the few fully free plugins thanks sponsorship from automatic and others!

  3. Thank you for the series, a plugin example fleshing out the theory will be very welcome.

    I look forward to the email notifications for your new posts, they are really useful for new WordPress development enthusiasts.

    • Thank you for the series, a plugin example fleshing out the theory will be very welcome.

      You’re welcome! If there’s time, I’d love to see what I can do, but it’s pretty low on the list of priorities at the moment. I don’t know if I’ll get a chance to come around to it, but we’ll see :).

Leave a Reply