Dive Into WordPress Custom Post Types – Part 1

Last updated November 6th, 2023 at 08:12 pm

WordPress introduced Custom Post Types on June 17, 2010, with the release of version 3.0. Custom Fields (in the form of meta_data) were part of WordPress since (I think) forever; developer tools for dramatically extending their functionality were added in March of 2008, with version 2.5.

I’ll admit I didn’t dive in right away myself.

What are Custom Post Types and Custom Fields — and Why/When Should You Use Them?

First: A little background on Post Types

Everyone who works with WordPress knows about the two main post types that have been part of WordPress since the beginning: Post and Page. The anatomy of these two post types — and the editor interfaces we use for both — are very similar, with only minor differences.

(Blog) Posts

The Post post type is typically used for blog posts, and these are normally (by default) displayed in a blog in reverse date order. Posts can be assigned Categories (and subcategories) and Tags, for the purpose of grouping similar topics together. Each can be assigned a manual excerpt (a misnomer, because it’s actually a summary or synopsis), and each can be assigned an unlimited number of sets of meta data (custom fields), although very few people use this function.

The article you’re currently reading is a Post.

Pages

The Page post type is typically used for the static pages of a Web site. Pages can have child pages (subpages), and they typically (by default) are not assigned Categories or Tags. The publication dates of Pages play no role in how they are displayed on the Web site’s front end — except for the fact that a post-dated page will not show up on the site until the publication date. Like Blog Posts, Pages can be assigned sets of meta data (custom fields), and like Blog Posts, very few people use this function. By default, Pages don’t support manual excerpts (synopses).

Custom Post Types (Finally!)

My rule of thumb:

Examples of Candidates for Custom Post Types

Here are just a few examples of content items that could be handled by the custom post type (and custom fields):

• Books you’ve authored (or read)
• Staff directory
• Testimonials
• Favorite movies
• Recipes
• Frequently Asked Questions
• Board of Directors

A book has a number of significant properties/attributes that you’d probably want to display on your site:

1. author(s)
2. publisher
3. publication date
4. genre
5. number of pages
6. synopsis
7. cover picture
8. etc.

For each staff member in a staff directory, you might want to display a number of properties other than name:

1. job title
2. department
3. telephone
4. email
5. school(s) attended
6. favorite quotation
7. etc.

Every testimonial might have, in addition to the testimonial text, these properties:

1. author name
2. author email
3. author company
4. author company website
5. author industry
6. author job title
7. etc.

And so on.

Why not just use Posts or Pages?

Theoretically, you could publish information about all your custom content (let’s use Books) as either posts or pages. But the default editor interfaces for posts and pages are not especially well suited for the particular properties/attributes of these content types.

What if we used the “Post” post type?

Let’s consider the workflow and potential pitfalls.

You could publish the details of each book as a post and assign it category of “book”. You could use tags for genre (Romance Novel; Cookbook; Self-Improvement; etc.). In the editor box, you would presumably enter the information with a standardized structure and format:

The book title would be the post title, so that’s taken care of. Then you might enter all the other book details, each on its own line, each potentially formatted in some special way. You might have the author’s name in bold; italicize the publication date; set off the synopsis in a box in a smaller font size and different font color; display a thumbnail of the book cover as a right-floated image; and so on.

Go ahead and Publish.

Now add another post for the details of another book. Assign it the appropriate category and tag(s). For the sake of uniformity of appearance, enter the details for this book in the same sequence and with the same formatting you used for Book #1. Publish.

One good thing about using the “Post” post type for your books is that WordPress will automatically display a listing (“archive”) of all book posts on the website page with this URL:

https://{your-site-domain}/category/book/

Do you see the potential problems?

For one thing, this sounds like a lot of work and a lot of remembering (especially the sequencing and formatting of details).

Secondly, since the detailed info for each book will be a blog post, they will — by default — be displayed on your blog in reverse chronological order: not necessarily ideal.

A huge problem with this approach is how difficult it will be to maintain and update the site when styling preferences change.

If you’re hard-coding the styling of details (rather than wrapping each detail in a CSS class), you’re in for a whole lot of pain when (not if) you decide later on you want some detail element to be displayed differently. Just imagine that you or the client decides that the color of the book’s synopsis should be a light shade of gray instead of black. You’d have to manually edit every instance of the book synopsis in every post in order to make the change and make it consistent.

Would it be better to use the “Page” post type?

If you’ve decided to use the page post type for the books and the master book listing, you’d avoid the reverse date-order sequencing problem, but you’d be preserving others and introducing a couple new ones, most significantly:

• Pages do not — by default — support categories or tags.
• Pages do not automatically generate archive listings, so you’d have to create (and maintain) one yourself.

In other words, you’d have to (1) create a master “Books” page that will serve as the listing of all books with links to the pages that contain their details. Presumably, that master “Books” page would list some of the information related to each Book, along with links to the dedicated pages for each book. And then, every time you add a new book page, (2) you’ll have to update the master “Books” page accordingly.

What about the custom fields meta boxes?

At this point, some of you are thinking, “Couldn’t I use the Custom Fields box to enter meta data about each book? Couldn’t I enter all the details there?”

The short answer is yes. The longer answer is that the Custom Fields box in the page/post editor interface is kludgy and not very intuitive. Plus, this approach will require you to either edit or create template files. Trust me… there’s a better way:

Create a custom post type (and custom fields) for each of those content types and properties.

Wait… Isn’t there a plugin for that?

“But wait a minute!” you’re thinking. “Aren’t there plugins for all of these content types?”

Indeed there are. Because many of the plugins you use on your Web site(s) have, as their foundations, custom post types and custom fields.

If there’s a plugin that handles your custom content, by all means use it. However, especially in cases where a plugin might be overkill, consider the DIY approach: create your own Custom Post Type and Custom Fields.

Why is the Custom Post Type/Custom Field Approach Better?

• Superior Workflow
  The add-edit interface for custom post types is an extremely efficient method for entering your content — no need to remember which element goes where. You fill in boxes.
• Uniformity & Consistency
  With custom post types, presentation and content are completely separate, ensuring that your content will be displayed in a consistent, uniform manner everywhere on your site.
• Display Anywhere
  Through the use of custom shortcodes, there will be no limit on how or where you can display your content.
• You’ll Never Go Back
  Once you get the hang of things, you’ll feel like a WordPress guru. Because you will be.

I can almost guarantee that once you dive into custom post types and custom fields, you’ll start seeing opportunities for using them everywhere.

But the Intimidation Factor…

Custom post types and custom fields can be intimidating because the code needed to create them looks complicated. In part 2 of this series, I’ll address the issue.

Join The Discussion

Please post your questions and comments in the comments section below. In particular, if you have some content type you think might be a good candidate for custom post types and custom fields, share your thoughts. I might use your use case in a future blog post — or even a tutorial!

Summary

While Custom Post Types and Custom Fields are separate and — theoretically — independent entities, I think it’s most helpful to think of them together. Like I said, you could add custom fields to blog posts and pages using the custom fields section of the editor, but that approach is far from ideal. And as for creating a custom post type without adding custom fields — well, I don’t even see the point.