Practical WordPress Development

Data Models in WordPress – Their Perspective, Not Ours

When it comes to treating WordPress as a web application foundation (and I dislike the use of the word framework, because that’s not what it is), one of things that I think that we, as developers, need to do a better job of doing is to introducing features that more conceptually map to the model of the data we are tasked with introducing for our users.

Sure, it’s one thing to introduce domain language into the solution that we’re building for our users, but there are greater strides that we can make in terms of introducing features and components that do a better job of mapping to the user’s problem.

Models in WordPress

In many modern web applications, design patterns are used in a way such that the data that’s stored in the underlying database is represented by some type of object in the application layer.

Then, at some point during the execution of the application, the data is retrieved from the database and then mapped to the attributes of an object. When changes occur to the object during the execution of the application, the data is saved back to the database.

Data Models: Databases to Objects

Data Models: Databases to Objects

For anyone who has written any type of application using something like MVC is familiar with this.

Of course, WordPress takes a different approach – and that’s fine. This isn’t about arguing which design pattern is best (though I know that’s a fun discussion to have).

Instead, this is about making sure that when we introduce a feature into an application for a user, we go the extra distance in making sure that what we’re displaying information on the screen that maps to what the user expects.

An Example With Events

Let’s say that a user wants to introduce the concept of an Event into their project where an event represents a day.

This means that the event has a few attributes:

  • Month
  • Day
  • Year
  • Hour
  • Minute

It may optionally have seconds, but you get the point. Then, let’s assume that an event can be one of the following:

  • Work day
  • Holiday
  • Weekend

Sure, this may be over simplified, but the point remains.

For those who are familiar with object-oriented design and are used to building things in that world, then we’re likely to think about an Events class that maintains a reference to a Time class which has the attributes of hours, minutes, seconds, and then perhaps even a Type class or a Type attribute that indicates what type of day or event it is.

But that’s not how WordPress works.

For those who are just getting started in WordPress development, it may seem easiest to do something like this:

  • Use the standard post type to represent an event where the title describes the name of the event, the content describes what will happen at the event or where the event is held, use a custom field for the time of the event, stamp the post with an ‘Event’ category, and then tag the event with whether or not it’s for ‘Work’, ‘Holiday’, or ‘Weekend.’

From a development standpoint, this isn’t too bad and it’d be relatively easy to query for the information in order to display the information on the screen.

But wait.

What user honestly thinks “Hey, In order to create a new event, I’ll hop into the Posts menu.”

This is where providing strong models in WordPress comes into play. So rather than using the default content types that WordPress provides, leverage it’s API to create something a bit more useful.

Try something like that.

1. Event Custom Post Type

Since data in WordPress is usually reduced to some type of content type or some type of taxonomy, create an Event custom post type where the title represents the name of the event, and the content represents the description.

2. Introduce Custom Taxonomies

Introduce taxonomies for the Event such that days can be work days, week days, weekends, holidays, and so on. Perhaps these can be hierarchical (because some week days are work days and some week days are holidays, for example).

3. Post Meta Data

After that, take advantage of post meta data to store any other information related to what constitutes an event.

This may include the start time, the end time, the list of people who are attending, the guest of honor, or whatever. Some of these can be optional, some of these may not.

Modeling The Data

As you can see, it’s really easy to come up with a way to represent traditional data model in WordPress permitting you’re familiar with a few key concepts.

The above isn’t meant to be a definitive guide for how to create, say, an Event in WordPress, but it’s meant to show how to invert our thinking from “How can we leverage the standard content types in WordPress to make the requirements fit?” to “What type of interface would be clearest to our users?”

That’s part of what software is all about: Modeling and solving real world problems with code. But in order to do that effectively, we need to make sure the work that we’re doing actually interfaces will with the people who will be using it.

We’re rarely building things for ourselves as much as we are for other people.

Not Our Perspective, Theirs

Finally, the point of this post is not to espouse one design pattern over another for modeling information, or to say that developers view things one way and that users view things another way and one way is more right that the other.

Instead, it’s meant to simply say this: When we’re building solutions for other people, make sure that we’re approaching the problem from their perspective rather than our own.

Leverage the domain language to make the code map to the language used in discussion, and take advantage of the WordPress APIs to introduce content types that do a good job of representing the real-world information from the user’s perspective.


  1. Mike

    Great post Tom! I love this quote:

    We’re rarely building things for ourselves as much as we are for other people.

    I found myself in a position like this recently, working on my updated portfolio, building it in WordPress rather than the one-page html site I currently have, and I was utilizing the custom content portfolio plugin from Justin Tadlock, but found some limitations to it, so I set out to write my own Work plugin, which let me add in the content how I wanted, utilizing custom taxonomies, etc.

    In creating that plugin, I added it to the repository so others could get use out of it, and already have some updates coming to it based on user feedback. In essence, I tackled the issue from a user perspective since it’s what I’d be personally using, but also am making sure my opinion on it isn’t the only one I’m taking into consideration.

    This way, the post type model I’ve built as a plugin can be used by as many people as possible.

    • Tom

      In creating that plugin, I added it to the repository so others could get use out of it, and already have some updates coming to it based on user feedback. In essence, I tackled the issue from a user perspective since it’s what I’d be personally using, but also am making sure my opinion on it isn’t the only one I’m taking into consideration.

      That’s awesome! The one challenge that always come with that is that every user always has feed back and so it can become a little bit of a challenge to push back against some requests.

      By that, I mean that each product usually has a vision and a mission and sometimes recommendations or feature requests don’t jive with that. Sometimes, that’s okay and it’s worth pursuing anyway; other times, it’s a matter of respectfully declining it.

  2. Mike

    Yeah, it’s definitely a balancing act. Right now, I’m looking to see which features get requested the most and giving them a bit more weight, as long as the request isn’t too far into left field for the goal of the plugin, which is to remain light weight and not over complicate things.

  3. Andrew Fielden

    For me the root of an application platform has got to be the way it handles the data model. I have no problem with the use of meta data rather than a direct to the SQL or an MVC approach however I do understand that there can be issues when it comes to maintenance if you have the just go for it approach that WordPress enables.

    I have jumped from the MVC world to WordPress as I am a great fan of the broad practical approach that WordPress takes to solving problems and the way that people are enabled to get into the game. For me the custom post types mean that I can build pretty much any type of application I want and as a result I cannot help but feel that WordPress is on the cusp of moving strongly into the areas that other more structured CMS systems have dominated.

    It is however difficult to maintain even my own code in relation to custom post types and I would suggest that it might be prudent to use an intermediary data class responsible for the retrieving and posting of data to the custom data type – I guess a controller of a sort. I know that using something like this would help in the code that I am making if just so that I know where I am putting all the business logic etc..

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑