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).

Continue reading

When programmers talk about entities, they are usually talking about a concept or something that has an existence within a system. Sometimes it’s a class, sometimes it’s a library or dependency, or it may be something like WordPress post types.

If WordPress is to be thought of as an application foundation (versus a framework), it’s important to think about certain features in ways that can be treated as entities. In the example above, a post type is just that.

When custom post types were introduced, it gave us a way to introduce something other than pages and posts into the application. Now we can implement any concept – like an event – and treat it as its own entity within the system.

But when all is said and done, it’s all saved in the posts table. And that’s fine because software development is all about abstraction. As we implement WordPress post types, we’re implementing an abstraction on top of the idea of posts.

Continue reading