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.