Last updated March 10th, 2023 at 10:27 am
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: author(s); publisher; publication date; genre; number of pages; synopsis; cover picture; etc.
For each staff member in a staff directory, you might want to display a number of properties other than name: job title; department; telephone; email; school(s) attended; favorite quotation; etc.
Every testimonial might have, in addition to the testimonial text, these properties: author name; author company; author industry; 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.
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 create the master “Books” blog post that will serve as the listing of all books with links to the posts that contain their details. Add that first book title into this listing and create the link. 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. Then edit your master “Books” listing and add the title and link for this second book. Publish.
Rinse and repeat.
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. Another potential problem is that if you are hard-coding the styling for the details (rather than wrapping each detail in a CSS class), you’re in for a lot of pain if you decide later on you want some detail element to be displayed differently (e.g., different color for the synopsis text). Even if you do use CSS classes to style the details, you’ve added another bunch of things to remember every time you create a new post for a new book.
Now suppose you’ve decided to use the page post type for the books and the master book listing. This avoids the reverse date-order sequencing problem, but it introduces another: pages do not — by default — support categories or tags.
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?
- 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.
- 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.
- Through the use of custom shortcodes, there will be no limit on how or where you can display your content.
- Once you get the hang of things, you’ll feel like a WordPress guru. Because you will be.
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.
Leave a Reply