As we enter the more advanced realms of custom WordPress development and client work, we want to find ways to make the entire experience easier for our clients. Most of our customers come to us to escape some outdated CMS where they’re copy-pasting chunks of HTML, always afraid that they’re going to break something because they’re really not sure what the other 95% of the code is doing anyway. We offer them WordPress because the experience is easy and if done right, means they’ll never even need to click the little /html/ button on the text editor. If our user can stay in Visual mode, protected from the vague uncertainties of sifting through HTML, we’ve done our job.
As we grow, so does our ability to offer custom solutions to clients. Anytime we add a significant amount of data, we know that there will be a lot of repetition, both during data entry, but also for displaying that data on the front-end. What follows is a series of tips, tricks, and tutorials based on what I’ve learned over the past few years of building steadily more complex websites with WordPress. We’ll follow a path of development that will take us from creating custom post types and fleshing them out with Custom Meta Boxes 2 to creating instantaneous interactions by accessing them via the REST API.
I’ll make some assumptions about my reader:
- You know how to build custom themes/plugins for WordPress, and do so semi-regularly for clients who need a custom WordPress setup. You may use child-themes, underscores, or something else, or perhaps you just like to start with an index.php, style.css and work from there. Either way, you feel comfortable in the loop.
As of right now, we’re looking at four parts, but this really could be subject to change:
- Preface – A Deeper Look at Posts (look down!)
- Part 1 – Data Organization Overall Concepts
- Part 2 – Custom Post Type Basics
- Part 3 – Extending Custom Post Types with CMB2
- Part 4 – Connecting Custom Post Types to the WP Rest API
Preface – A Deeper Look at Posts
To better understand custom post types, we should first take a look back at the underlying concepts of WordPress and ‘posts’ in general. It’s important to remember that WordPress was first and foremost a blogging platform before it began to be taken seriously as a full-fledged Content Management System or CMS. While nowadays it feels pretty acceptable to consider WordPress as a CMS, the roots in blogging still pervade everything WordPress development, and it’s useful to continue in these terms.
In this section, we are going to try to understand what and why posts exist within WordPress.
What Are Posts?
I mentioned earlier that almost everything on WordPress is a custom post type, so let’s explore that further by looking at the default post.
A post is really the result of what is often called a CRUD operation in computer programming. CRUD stands for Create, Read, Update, and Delete – the four basic operations we can do with our data. We can create/update/delete some data (generally through the WP-Admin) and we (and our users) can read the data (displayed through the front-end of the site in the form of pages and posts. In WordPress, a post is just the base type of CRUD content, or even more simply, a post is content.
Because that content generally follows a specific pattern, it’s been bundled together in what is formally called a Post. Creating a post basically allows us to populate the following fields:
- Some written content or ‘body’ text
- A title
- An author or record of which user created it
- A thumbnail or ‘featured image’
- Additional meta or information about the post
These elements form the basis of what we think of as a blog post, but these are the same foundational elements used to populate pages on a website and even file attachments. While this list of features is not comprehensive even for the default posts on WordPress (as we’ve left out date-stamps, previously saved versions, comments on the post, etc), it is useful in terms of understanding how data is stored on WordPress.
What we’re mostly interested in is that last bullet point, known as post meta. Meta generally means ‘about itself’ and so is used to store things about the post itself, like which categories it belongs to or how its being tagged. However, we can take advantage of our ability to get post meta, through a function named
get_post_meta(), and we can use it to store all sorts of extra data, whether its names and locations, addresses, countries, or additional media like URLs, images, or videos.
So posts, then, become the standard currency of data and content in our WordPress, and when we leverage the ability to create our own custom content types, we have the power to transform our simple blogging platform into a robust content management system.
When Not to Create a Custom Post Type
When your dealing with more blog posts.
Custom Post Types really are meant to be just that, custom. They should break the mold somehow and probably require the storage of data that is unique to itself. If the If you’re thinking of adding a ‘news’ section or a ‘press’ section to a site, chances are you can get away with just using categories on your blog posts.
When your data needs to be relational and simultaneously collaborative.
It is also important to note that WordPress doesn’t store all of this data in the most advanced relational databases with content synchronized in real-time lightning quick JSON with a few other buzzwords thrown in for good measure. The MySQL databases that store this data are tried and true, but not meant for advanced application building. Don’t think we can use this to create the next Google Docs or Dropbox. Custom post types are really meant for storing content, not facilitating advanced interactions.
That being said, there is a lot of potential with WordPress and the Rest API, as we’ll see in later posts. One of the benefits of WordPress and it’s reliance on MySQL is that it’s simple to set up and are usually included with the most basic of web hosting packages. It’s certainly a more democratized approach to web development and it allows you to own your data at an even deeper level, not subject to the whims of a fast changing tech field.
As you plan out the architecture of what you’re building, always spend some time evaluating the pros and cons of each platform and each method before you start digging your hole.
Custom WordPress Preface Overview
This brief article was meant to provide a deeper understanding of what a post is in the context of WordPress. We examined the basic CRUD operations that underlie all data, and we took a look at the basic elements of a post. Then we examined the concept of ‘meta’ information as it applies to posts and the potential for custom post types. Finally, we took some time to explore when not to use custom post types, when regular posts could apply or the chance that we might need something outside of the scope of WordPress.
Continue on to Part 1 – Data Organization Overall Concepts as we examine what posts really are and how they can be effect ways to store our content.