• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

nSiteful Web Builders

Building a Better Web - One Site at a Time.

  • Home
  • About
    • Testimonials
    • Resources
  • Web Sites
  • Online Marketing
  • WordPress Support
    • Customized WordPress Training
    • 60-for-60 Sessions
  • Web Applications
  • Blog
    • Archive Listing Minimalistic
    • Blog Articles Grouped by Category
    • Case Studies
    • General
    • Portfolio
    • Reviews
    • Snippets
    • Techniques
  • Contact Jeff
    • Purchase Retainer Consulting Hours
    • About Retainer Consulting Hours

By Jeff Cohan, October 10, 2018

Dive Into WordPress Custom Post Types – Part 1

Last updated March 10th, 2023 at 10:27 am

dive into preamble

This is one of a series of articles about the why/when/how of WordPress Custom Post Types (CPTs). The articles are geared to WordPress developers who may have little or no experience with custom post types, with the hope that what I share will remove some of the mystery associated with CPTs and encourage some of you to dive right in.

toc for dive into cpt

Posts in this Series

  1. Dive Into WordPress Custom Post Types – Part 1
  2. Dive Into WordPress Custom Post Types – Part 2
  3. Dive Into WordPress Custom Post Types – Part 3

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

I think it’s unfortunate that WordPress uses the term “Post” in both the generic and specific sense. So, a Post is a Post and a Page is a Post. That’s potentially confusing. Similarly, it might have been best if WordPress used Custom Content Type rather than Custom Post Type. But whatever.

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:
My rule of thumb is that a Custom Post Type — combined with custom templates, custom fields (usually), and custom taxonomies (often) — is great solution for any type of content that has a unique set of properties/attributes and that you would want to display — as efficiently and consistently as possible — both in a listing that shows all (or groups of) content items and as individual “pages”, each of which shows just one content item at a time.
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 use standard posts or pages to present custom content. However, you’re asking for a whole lot of pain if you ask me. The workflow would be horrendous, and the chances of achieving consistency and uniformity in displaying your content are quite low.

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.

Screen capture of custom fields meta boxes
Click to see meta boxes enlarged

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?

screenshot of WordPress plugins repository“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.

Related Posts

  1. Dive Into WordPress Custom Post Types – Part 3
  2. Dive Into WordPress Custom Post Types – Part 2
  3. Making Sense of WordPress Post Formats
  4. Use Custom Fields to Hide Stale Posts
  5. How to Create a Simple Custom Events Plugin
  • Choose the best match.

Written by Jeff Cohan · Categorized: Techniques · Tagged: Advanced Custom Fields, Custom Fields, Custom Post Types, WordPress

  • Choose the best match.

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

mailchimp signup

Subscribe to get notified when new articles are published. Unsubscribe any time. No spam. I promise. Check out my newsletter archives.

social

Twitter Facebook LinkedIn

Recent Articles

  • Use Case for Custom Post Type: “In The News” March 10, 2023
  • Create a Custom Shortcode to Display a MemberPress Membership Price ANYWHERE on Your Website February 5, 2023
  • Avoid Direct Styling; Use CSS Instead September 21, 2022
  • Blog Tags: What They Are (and What They’re Not) August 5, 2022
  • How to Create a Simple Custom Events Plugin May 24, 2022

Filter By Category/Tag

Categories

  • Case Studies (7)
  • General (61)
  • Portfolio (5)
  • Reviews (12)
  • Snippets (16)
  • Techniques (38)

Popular Tags

Advanced Custom Fields Blogging Child Themes Content Marketing CSS CSS Grid Customer Service Custom Fields Custom Post Types Diagnostics Facebook FooGallery Genesis Gutenberg HTML Images iPhone Libra Live Chat Marketing Media MemberPress MemberPress Courses mu-plugins MySQL Photo Gallery php Pinterest Plugins Post Formats Pricing Project Management Security SEO Seth Godin Shortcodes Social Networking Surveys Taxonomies Trello Twitter Video Web design Web forms WordPress

siteground wp hosting

Web Hosting

wp101

EasyWordPresstutorialvideosforbeginners.
MemberPress CTA

Footer

Background

Web Sites | WordPress Support | Web Applications.

Formally trained in liberal arts and education (I have a B.A. in Government from Harvard and studied Secondary Education at Rutgers Graduate School), I have honed my skills in the communication arts and sciences as a teacher, trainer, instructional designer, writer, photographer, calligrapher, helpdesk manager, database programmer, and multimedia developer.

(I've also been a group counselor, waiter, bartender, bicycle messenger boy, computer salesman, carpenter's helper, financial analyst, and school board president.)

Tech

Systems since 1983.
Web sites since 1994.
PHP since 2001.
WordPress since 2007.

Contact

770-772-5134
Email Jeff
Send Money
All Ways

Copyright 2023, nSiteful Web Builders, Inc.

 

Subscribe

Pardon the interruption. I know popups can be annoying. But I’d love to have you as a subscriber.

Sign up to be notified when new articles are published. Unsubscribe any time.

* indicates required

Powered by MailChimp

×