Custom Post Types Are Not Posts

Written by

Brady Vercher

in

Custom post types are not posts.

However, posts are a specific implementation of a CPT. As are pages. And nav menu items. And revisions. Oh, and attachments, too. Hell, at some point, comments could probably even be integrated as CPTs. Are all of these objects the same just because they’re CPTs? See where I’m going with this?

CPTs are not posts.

For most intents and purposes, forget that “Post” is even part of the name.

There has been a little discussion around the usage of CPTs and shortcodes in WordPress themes meant for public release over the past week or two. It’s actually been an ongoing discussion for awhile, but it recently heated up a bit and sparked a few reactions.

The data portability issues fueling the discussions about including CPTs like portfolio items in a theme are ones of standards and generating wider buy-in from the community — they are not technical issues.

But is seamless data portability really the ultimate overriding concern? So much so that it limits what themes built for a specialized purpose can do? Sure, posts are going to be present in almost every installation of WordPress, but when they’re used for things like portfolio items, it actually forces restrictions on the permalink structure, and those objects will become posts when a theme is switched. Can you even call that data portability? In one instance the data still exists, it’s just hidden; in the other, the content’s meaning seems to have changed based on its presentation.

So is it really a good thing that the data is exposed even though the content is now being represented differently? Nay, I say. A portfolio item is not a post, either.

Chasing that tangent for a moment, using posts for portfolio items, and thus as an example for discussions like this, never really made sense to me because they are static content that more closely aligns with the way pages work. And WordPress actually provides a way to handle custom page templates. Create a page, assign it the “Portfolio Item” page template, have the user insert the standard “gallery” shortcode, override the shortcode’s output in the template for custom display, and you have a totally portable way to add portfolio support without imposing restrictions on permalinks (give me back my /blog/ base, please) or misrepresenting the content when the theme is switched.

And a quick word about shortcodes.

They can be useful. They’re easy to implement and can provide powerful functionality (in addition to unnecessary and arbitrary markup). They’re also a horrendous way to define and manage columns. Why is anyone wasting time focusing on creating a better column shortcode instead of building a user interface elegant enough that users demand support for it from theme authors, and potentially have it incorporated into core.

The plugin approach shouldn’t be only about standardizing shortcode usage — it should be about creating better, easier to use solutions for making widely used shortcodes obsolete.

In both cases, data portability should be an important goal, but it shouldn’t be an absolutely limiting factor for themes created to serve wildly different purposes or niches — and users should understand this.

Author’s Note: I haven’t released any themes for distribution (unless you count a couple we did way back in 2005 that have hopefully been eradicated from the internet), but do plan to rectify that at some point (@see AudioTheme). In the work we do for our clients here at Blazer Six, these issues are mostly a moot point, however we have worked with plenty of commercial themes, so I figured I’d throw out a few thoughts for whatever they’re worth.

Comments

6 responses to “Custom Post Types Are Not Posts”

  1. Thoughts on Custom Post Types and Data Portability in WordPress Themes

    […] EDIT: As a preface, I completely agree with “Custom Post Types Are Not Posts“. […]

    Reply
  2. Mike McAlister Avatar
    Mike McAlister

    You have some great thoughts here, Brady! Custom post types are definitely not posts. It’s been said many times that they should have been named something more telling, like custom content types, which would better describe their purpose.

    I would agree that portfolio items are more static in nature, but at the same time I’m not opposed to having that kind of content in posts, depending on the theme of course. But I look at the Posts section a little differently than the majority of people. I’m looking at how it can be utilized going forward, versus how it’s been utilized in the past. I think there is a great potential there that can serve more than just a /blog section.

    As mentioned in my article, I do use posts for portfolio items, and haven’t had any residual effects or adverse reactions to using posts this way. By all means, that doesn’t mean I’m right or wrong in my methods, but it has worked out well thus far for the commercial buyers and myself.

    I was curious what you meant about compromising the permalink with posts? I’m able to retain the same kind of /portfolio/portfolio-post and blog/blog-post that you would get with a CPT. Also curious what you mean when you say “the data still exists, it’s just hidden.” Maybe I setup my portfolio items a little differently, but they don’t seem to be as susceptible to these kinds of issues.

    Always good to hear another developer’s perspective. Keeps me on the hunt for the best way to do things. BTW, love the site and the beard!

    Reply
    1. Brady Vercher Avatar
      Brady Vercher

      Hi Mike, thanks for dropping by! I might be a little long-winded, but I’ll see if I can make my points a little more clear. And thanks for the compliments on the site! The beard is grateful, too.

      I’m all for creative usage of the tools available, but if data portability is a major concern, then I think certain guidelines need to be followed, and that’s probably why posts have mostly been utilized in a limited way to this point. I know they can be made to do just about anything, and it’s nice that they’re available in every basic installation of WordPress, but when switching themes, the semantic meaning of content can change drastically if it’s handled differently.

      In some cases it may not be a big deal, while in others it might make a huge difference. Or maybe users just don’t switch themes all that often and they understand that they can’t expect the transition to be seamless?

      Permalinks

      I’m guessing you’re probably using something like /%category%/%postname%/ for your permalinks and I can see how that would work. (I’ve never really been a big fan of category slugs in the permalinks, but couldn’t really tell you why.) That does, however, force a particular structure on the user, which might not be so bad for a new site, but what about someone with an established site?

      Typically my structure would be something like /blog/%postname%/, which prepends post slugs with /blog/. So if I were to switch to a theme using portfolio items like yours, my permalink would look like this: /blog/portfolio/portfolio-item/. And using a date-based structure would be even more unclear.

      Then again, I could be missing something simple.

      Hidden Data

      The “hidden” remark was in regards to switching from a theme with an integrated CPT to one without. The data stored as a CPT from the previous theme isn’t deleted, it’s just hidden in the database and would need to be exposed via a plugin. In any case, switching themes shouldn’t change the semantic meaning of that content. Ideally, this is where a standard would come into play and allow plugins to add support for popular content types.

      Whereas switching from a theme that uses posts to store custom (possibly static) content like a portfolio item, causes the semantic meaning of that content to be changed when a new theme presents it differently.

      Of course you have more real experience distributing themes on a broader scale and I’m not trying to convince you to do anything differently, I just thought I’d weigh in with my thoughts in regards to the conversation.

      Semantics and standards can be a tedious thing.

    2. Mike McAlister Avatar
      Mike McAlister

      No worries, I love the commentary. I’m not convinced my method is necessarily the best, so I appreciate hearing your thoughts. We’re on the same page with both of my questions, I just wanted to be sure I wasn’t missing something.

      There’s definitely a case for both the permalink and data representation situations, and I’m always revisiting both. It does get exponentially trickier when you are leveraging with the mass market. Would the average user forgo a preferred permalink structure in favor of not having to port over a CPT themselves? Probably. The average user doesn’t even know what a CPT is, let alone how to manage it. It’s not an ideal compromise, but it’s a safe one. At least until we can define that standard, semantic solution to satisfy every user.

      This is where I go into my spiel about why WordPress isn’t as user friendly as it could/should be (another day, I suppose). But this kind of decision/imposition shouldn’t be placed on a theme user. They shouldn’t have to worry how to get their data from one theme to the next. It should be seamless. It should be Automattic.

    3. Brady Vercher Avatar
      Brady Vercher

      Regarding the permalinks, how well does the portfolio work for users that have an already established structure? Do they not worry about it if they have a non-category based structure? Just curious on that front.

      I’d probably opt for a plugin for something I didn’t feel like should be defined as a post, but I can understand where you’re coming from. Otherwise, I think we’re mostly on the same page.

      It’d be easy enough to build a plugin with the flexibility to handle a wide range of scenarios, it’s just getting enough theme authors to adopt it to make it a standard that I view as the main issue.

    4. Mike McAlister Avatar
      Mike McAlister

      Honestly, it’s only come up a few times over the years. For the users who were concerned, I’ve helped find a compromise. Either direct them to a plugin or just give them some tips on basic search engine redirects to help them bridge the gap. I’ve found many users have a structure that can accommodate the portfolio items as posts rather painlessly.

      The idea of a multipurpose CPT plugin has been brought up a few times lately. I would love to see that come to standardization. Gotta get everyone on the same page first!

Leave a Reply

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

More posts