A recent thread over on the ThemeForest forums has sparked debate again about the best practices when using shortcodes and custom post types in commercial WordPress themes. Namely, whether these kinds of features should be coded into the theme itself, or if that functionality is better served in a plugin. The likes of Justin Tadlock, Carl Hancock and Pippin Williamson weighed in with their opinions, which favored using shortcodes and CPT’s in a plugin. Several ThemeForest authors showed resistance to this idea, claiming it’s better for business to include them with the theme.
So instead of having the same dialog again and again and again, let me just save us all some time here: They belong in a plugin. For one million reasons, they belong in a plugin. WordPress professionals like Justin, Carl, Pippin and the codex all agree.
Presentation Vs. Functionality: Since the purpose of Themes is to define the presentation of user content, Themes must not be used to define the generation of user content, or to define Theme-independent site options or functionality.
Does your theme include custom post types? Do those custom post types create content? Do not pass go, do not collect $200! So there’s that. Seems pretty straight forward to me.
Obviously CPT’s have their place, I don’t think we need to have that discussion again. But for the sake of small-to-average sized, commercial WordPress themes, why do developers feel like they absolutely must have them?
The never ending 300-style battle for CPT’s in commercial themes has never made much sense to me. That might be because I don’t use CPT’s in my commercial WordPress themes. I never have. I gave up CPT’s when I gave up client work. Back then CPT’s were pretty much a pain in the ass to deal with anyway, so it was an easy decision to make. I knew of the dangers of wrapping up a user’s content in them, but I didn’t have the insight to circumvent the issue with something like a plugin at the time. What a n00b! So my thinking was, I’ll just come up with a way to work with what WordPress gives every user, no matter what kind of setup they have. Enter posts and pages.
I don’t use CPT’s in my commercial WordPress themes.
All of my themes work the same way. Your content, whether it be blog posts or portfolio items, is stored in categorized posts and pages. Weird, huh?! Based on what category you assign, those posts will be used to populate different parts of the theme. This distinction is defined by one of the few theme options I provide. “What category would you like to populate your portfolio with?” And based on their selection, the theme will utilize that to either include or exclude the portfolio, blog posts, etc.
And that’s it, really. Users know how to use posts and users know how to use categories. It’s incredibly straight forward and requires no special treatment of their content on import or export. And given the relatively limited lifespan of a theme, I think this is a fair compromise for the ease of use and portability of content.
Trying to anticipate what every single user is going to do with their content is impossible. On top of that, the skill of the user varies greatly from buyer to buyer. But we can take advantage of some of the constants. There will always be posts, pages and categories. I would argue that users leaving with all of their content in categorized posts and pages is better than leaving with only some of their content and having lost their portfolio because of a theme developer’s mismanagement of their content. Or because they aren’t able to transport that content themselves. The potentiality of a user (let alone a developer) mishandling a CPT is infinite.
Ideally, a user should leave a theme with all of their content, especially if their CPT’s are responsibly transported with a plugin. Some developers are doing this right, most developers are doing it wrong. Even with the developers who are doing it right, there seems to be a lack in standard naming conventions for CPT’s, making the transition that much harder. That’s another post entirely. Standards, amirite?!
The argument can (and has) been made that the separation of content between posts and custom post types, like portfolios, is more beneficial to the user. It’s more intuitive. I can definitely agree with that to an extent. Again, this all depends on the site. I deal with a lot of themes with a portfolio. A user sees a portfolio menu, they assume it’s for the portfolio. A novel concept. But if that portfolio menu wasn’t there, would users lose their shit, run around pulling their hair out and demand a refund? I can tell you from my experiences, they do not exhibit this kind of behavior. They just act like normal people and use the posts and pages with no quarrels because that’s what WordPress is built to do.
In larger sites, where you have tons of posts and pages or content that needs particular treatment or manipulation, you would probably benefit from a CPT or two or ten thousand (you go girl!). It really depends on the site’s purpose and size, and also the user. But for your average commercial WordPress theme user, which is the market I’m dealing with, I don’t feel the need to make that headache distinction for them by default. These users are creating an average of 5-10 pages and 20-40 posts — a perfectly manageable amount of content, with or without a CPT. And introducing a CPT into that ecosystem seems like an unnecessary distraction to me.
Maybe my absurd use of posts isn’t so crazy after all. It depends on how you define the use of the Posts section. It seems like most people still consider posts to be strictly for use in the blog of a WordPress theme. Rightfully so, since this was the very essence of WordPress for years. But now we’re seeing a definitive shift in how WordPress is being used. WordPress.org defines WordPress as the following:
WordPress started as just a blogging system, but has evolved to be used as full content management system and so much more through the thousands of plugins, widgets, and themes, WordPress is limited only by your imagination.
Even the latest default theme, Twenty Twelve, is setup more like a website than a blog. Of course it has a blog, but for the first time it’s secondary to the homepage. This pivot has been happening for years now, particularly with the popularity of commercial theme marketplaces. Most of these commercial themes provide the layout and styling of a full-fledged website versus just a blog with posts. I keep it real with a few blog-style themes every once in a while, but my focus has also shifted to business style sites, portfolios, and the like.
So based on this pivot, should we limit the use of Posts section to just blog posts? Or are we stuck in the mentality that posts should serve a sole purpose? Posts are incredibly powerful and perfectly manageable on their own, especially if you’re crafty with how you use them. Not utilizing them for something as simple as a portfolio item seems like a waste of core functionality. Especially given headaches that still surround CPT’s in commercial themes.
For me, the disadvantages of CPT’s in commercial themes still outweigh the advantages. And so, for now I’ll carry on without them. That’s not to say that I won’t use them in the future or wouldn’t if the theme called for it. But if I do use them, you better believe they are going to be in a plugin. For now, I don’t see a reason to switch my themes over to using CPT’s.
I’m not trying to use this article to justify whether my practices are right or wrong. Certainly plenty of people will disagree with my methods. What I do know is that this model works for me, and it works for my customers. I’m always experimenting and looking for the best user experience. Of the 10,000+ themes I’ve sold to date, I haven’t had any issues with the method I’ve chosen. No complaints about the lack of CPT’s or the way I handle posts from users switching to my themes, using my themes, or switching away from my themes. Nor do I field any questions about this in the support forum.
We all have ideas about what we think is better for the user, but in the end they will decide what works best for them, and they’ll be plenty vocal if it doesn’t work. I think there’s plenty of room for innovation of how we each use WordPress, as long as we’re respectful of our user’s content.
It’s inevitable that a handful of people will read this and jump to the obtuse conclusion that I’m trying to radically replace the use of CPT’s with standard posts. As I stated earlier, that’s not the conversation we’re having here. CPT’s are incredibly powerful and have advantages that would benefit many situations. My objection is to blindly falling back on CPT’s in widely-distributed commercial themes, when there are potentially simpler, alternative ways to handle content at your fingertips.
When I built my first WordPress site portfolio items were one of the most difficult pieces of content to work with. This was pre-3.0, so custom post type weren’t really a viable option. I struggled with how to organize this content. Were they posts? Were they pages? Neither, really. I tried both. I even used Flutter, a now defunct plugin, that attempted to do post types before they were supported in core.
For me, Portfolio items were unique content that I wanted to style differently, tag differently, add special custom meta fields to, and keep completely separate from my blog content and regular pages.
So, a couple weeks after WordPress 3.0 was released, I submitted “Portfolio Press” to the WordPress theme repository. Custom post types were originally baked in, but eventually I came to my senses and migrated that functionality to a plugin (http://wordpress.org/extend/plugins/portfolio-post-type).
However, I do understand where you are coming from when you say that custom post types should not be used in most themes (commercial or not). I think most users primarily care about the presentation of their content, and if you can make that work as a regular post without jumping through code hoops to get them there, I’m for it.
I occasionally get questions from people who want to mix their “portfolio” content with their “blog” content, and I realized I’ve failed to explain the difference between the two adequately. I think regular posts are definitely a safer and more flexible option for the general user in the long term.
I’ve used your Portfolio Post Type plugin several times for a few of my own side projects. Very smooth.
I’m sure there will be a day when I would like to elaborate on my portfolio displays and utilize a CPT. Any day now, actually. If only I knew of a plugin that would help me with this…
[...] “I Don’t Use Custom Post Types In My Commercial WordPress Themes“: Mike McAlister sells themes (and he sells tons of it), yet he doesn’t use CPT feature for his themes. His argument is that there are cases where using Post and Page is simpler to handle user’s content. Selling commercial theme is one such case, and he hasn’t had any problem with his users from that decision. [...]
I am in agreement with you, Mike, 300%. The rule of thumb I try to apply is, if we are interacting with content that is saved to the database, that should be a plugin. This allows the the user to switch themes freely and not worry about what will happen to their hard work writing all of those custom post type posts.
The two premium themes we have released to date, that include a portfolio CPT, did so using the plugin method but in an ass backwards way. Instead of including instructions to install the plugin into their plugins directory, I used
require_once()to load the plugin files via the functions file. I quickly learned that I was setting us up for failure though.Though I know how to move these files to the plugins directory manually, the average user would not. This meant I would have to write some extensive documentation on how to do so, in the event you want to change your theme. Fail. The second problem was, for each theme we want to include this bit of functionality, I had to either copy & paste code or write the code from the ground up. For whatever reason, I chose the latter which introduced another set of problems which I won’t go into.
In the end, we have decided that we are rolling our portfolio CPT into an installable plugin which we hope to release to the repository. This way, everyone wins. If you purchase one of our themes and do not want the portfolio functionality, do not install the plugin. If you have installed the plugin and we release an update to the plugin, there is no need for us to update the theme.
I don’t have all of the answers but this feels right for us. As you said,
I read that thread on TF recently as well. I was happy to read your thoughts, which I pretty much agree with as written.
Perhaps I’m different than many buyers, but I *expect* that switching between themes is going to take a little work. Even if my portfolio CPT comes from a plugin that is handled well, the likelihood that the new theme work nicely with the thing has proven to be low, for a variety of reasons. I see other buyers complaining that things didn’t move over neatly, but with the state of many themes (and plugins) right now, how can they? Regardless of realistic expectations (or not), and regardless of whether you use CPTs or not, in a plugin or not, there is definite room for improvement.
Your style, Mike, the clever ways you implement standard Posts, have always been easy to work with on sites that I have later transitioned to another theme. However, I don’t make my purchase decisions based on planning to change your theme out regularly. I don’t only expect that “changing franchise” a year or two down the road is going to take a little work, I rely on that effort to give me the time/motivation to clean house a little bit.
My perspective is problably of little help for developers who need to distribute their themes widely. You can’t rely on buyers to be able to do much (if any…) grunt work, or take the time to learn how to do even simple things. Doing so is denying reality. Should we (buyers) take responsibility to learn how to do some things? I say yes. But, unless you serve a niche of skilled buyers only, this isn’t going to work in your favor.
Whether you use CPTs or do something ‘crafty’ with standard Posts, the effort you put into making things work smoothly both during content generation and when moving that content does has a pay off. If your theme (and/or plugin) made my life easier when I write, didn’t have a bunch of problems I had to figure out, etc, I’m going to look at your portfolio first when I want to change themes. If I buy a new theme from you and I don’t lose things in the transition and transition is generally flawless, I’ll buy your work forever. Even if I don’t need it.
Getting back to the topic, there are some situations for which I actually prefer CPTs. It’s more about making sense and ease of use than anything else. A well-coded, intuitive, standards-focused CPT plugin is a joy to work with. Using standard Posts and Pages and leaving CPTs out of it can also be fantastic, so long as they have been implemented with good code and practices, and the manner of using them is simple and well thought-out (all of which, btw, Mike does beautifully). Regardless of how you deal with this sort of content, gold is gold and crap is crap. From my perspective, it’s not CPTs or standard Posts that make something great, it’s the care you put into developing the solution.
So, my advice is, think it through. Does your theme NEED a CPT? Why. How would you justify it? Would you put the CPT in if you were building the site for your PERSONAL use only? Or is it going in because it’s the way you think the buyers want it? Certainly don’t put it in just because you think you need to market your theme by saying “(# of) custom post types included in theme.” Which brings me to another topic. Even if you can justify using custom post types, you should be marketing it saying “(# of) custom post types available using the following plugin(s)”
In short: use a CPT if it’s how you’d make it for your own personal project, but don’t just throw it in because it’s trendy or because your marketplace lets you set a higher price if you have lots of extra crap in your theme. LISTEN TO MIKE. He’s smart, and he’s RIGHT. Throw that shit in a (good) plugin, or use an existing (good) plugin.
[...] haven’t put my two cents in anywhere on the recent discussions on Custom Post Types in WordPress themes. I do not have the answers though I figured I [...]