Never miss a thing!

Sign up to have the latest news and announcements from my site delivered straight to your inbox.
  • This field is for validation purposes and should be left unchanged.

Reader Interactions


  1. Great tutorial Carrie! Thanks for taking the time to post about this. No harm in asking if you A) don’t recall the process, or B) don’t know the answer. I find, at least for myself, that asking questions is the best way to learn. I have been known, in my school days, to be severely persistent question after question. In the end, I always ended up as the “go-to” gal, exactly because I understood well the what not-to-do’s and what to-do’s properly. Where as I find, IMO, most folks are too embarrassed or scared to ask. For the most part, I don’t care what other folks think of me asking a lot of questions, especially if it means getting the answers I need.

    Separately, this is a great, handy tutorial you’ve posted there. I’ll admit, that when I first started dabbling into PHP, I did exactly what you’re not supposed to do, add it in the theme itself. Mostly, for me it had a lot to do with I didn’t understand the best practices, even though I was searching and reading the right answers. One of my drawbacks to learning is that I’m often needing too much of a visual guide and find it hard to follow the WordPress best practices. Maybe, this is the case with most newbies, as it all seems so overwhelming to put into play and understand fully. To date, I’m still learning the best practices and hope to continue improving those skills. I

    t’s developers like you that make the development community a nicer place to be a part of. It’s hard enough trying to follow and learn everything there is to learn web related. And oh boy, is there a lot to be learned… Anyway, thank you for your kind support and post. I’m sure many, including myself will find this tutorial useful along the way. Have a super fantastic week! πŸ™‚

    • Hey Cindy,
      Thanks for the comment (and the original question!). You don’t know what you don’t know… I’m pretty sure I violate some best practice or another every day, but to your point, we’re all learning/improving as we go. πŸ™‚

  2. Hey, this is great. I’m compiling a list of “best practices” for WordPress “Builders” and will add this post about separating content from themes. My list is a brain dump for people like me who learned and are learning along the way how to create sites for others as @MattMedeiros discusses (so glad he commented – I need to put him on the list, too!).

    I created this for my local WP community and students, but I’d love to share and get feedback, input, links, etc. It was like my brain going splat on a page.

  3. Great post Carrie. I’ve been scratching my head about this for a while. Some themes have them, some don’t. Your examples illustrate the proper way to approach this. I like your core functionality plugin solution.

  4. Thanks for being brave enough to tell us what you wish you had done differently. I was inspired to use Custom Post Types right here on your blog (WP-Types +Gravity Forms post). So cool. I have to admit that I became a hammer and, for a while, all the world was a nail. I still LOVE love LOVE custom post types, but most of the time, custom styles for for tags/cats are all I need. *sigh*

  5. Thanks so much for this. As a developer who’s still learning as well, I find that the line between best practices and special cases blur in an agency setting. In the agencies I’ve worked for, projects are especially planned for months and built specifically for that individual client. So I guess the assumption is the client isn’t going to change themes (or we don’t want them to because we want them to come back to us for maintenance = more profit).

    However, I’ve also noticed that not following certain practices end up becoming a headache later on. The client installs a plugin they expect to work but the customization went too far and won’t allow it due to interfering what should “come out of the box” already. Or maybe the client hates the theme we built for them a year or two later and decides it’s time to reboot! Or the client has an existing site with existing custom post types that we’re re-building a theme for. The list goes on.

    I realize Justin’s article specifically mentions that it’s based on publicly distributed themes/plugins. My question would be, at what point do these practices apply to all themes/plugins public or client private? What practices are specifically for an in-agency setting? Or rather, for a situation where the theme is custom to that client only and won’t be distributed.

    This is something I’m trying to clear up for myself every day. Would love to get that perspective or be pointed in the direction of someone who can share that perspective? πŸ™‚

    Thanks again for all the resources! Definitely gonna make use of these.

  6. @Rachel Coming from a blogger point of view I sure don’t want to be locked into ANY theme including those custom built for me. I dumped Themify because it was so hard to just change between their own themes. When I departed them it was a lot of work to get my blog back to normal. I learned my lesson and began using Justin Tadlock’s stargazer theme.

    I appreciate your clarifications Carrie – this article is invaluable for us non-developers as well – thank you for even including examples that further clarify do’s and don’ts.

  7. Since the primary issue my article dealt with was within publicly-distributed themes, I added the note so that I’d have to stop reading comments about irrelevant exceptions to the rule in an agency setting. I’d say 99% of the time, this rule applies to client work. It’s just a slightly different set of issues because clients aren’t changing themes on a whim.

    If it can be put into a plugin it should be. It’ll save you (or some other developer) headaches in the future. Separation of form and function is something we should all strive for, despite the setting.

    With that said, there are certainly instances for specific clients where you need to break the rule. That’s a decision you have to make on a case-by-case basis.

    • Yes.

      If it can be put into a plugin it should be. It’ll save you (or some other developer) headaches in the future. Separation of form and function is something we should all strive for, despite the setting.

  8. > My question would be, at what point do these practices apply to all themes/plugins public or client private?

    Short answer: they always apply. Always.

    Long answer: everything on your site, be it a theme or a plugin, should be self-contained to its specific purpose. A plugin that does two entirely different and separate things, with nothing in common between them other than they were made by the same person or for the same site, is a bad plugin. A theme that does things not related to the display of the site is a bad theme. Simple, really.

    One plugin or a dozen makes no difference when it is just a matter of the same code in one file or a dozen. Only the amount and quality of code matters. Not how you divide it up. How you divide it up affects how you write it, and how you think about it. That matters a fair amount. You’re less likely to add in needless interdependencies when you enforce a separation of code in your brain.

    • So you’re anti a core functionality plugin (key word being *core*) if it registers CPTS, registers taxonomies, & defines some metaboxes? Or is that an example of things that are closely-enough related…

      One plugin or a dozen makes no difference when it is just a matter of the same code in one file or a dozen. Only the amount and quality of code matters. Not how you divide it up.

      ^^ Thank you for this. I’ve been meaning to write a post expounding on the topic of “too many plugins is bad.”

  9. Only if those things are unrelated. Like, you wouldn’t want to mix a plugin that adds a taxonomy to help organize your photos and a plugin that adds a CPT for, say, Portfolio posts. Those are unrelated things.

    Keeping only related things grouped together makes it easier to debug because you can disable individual pieces of the site without affecting the rest. That’s the real power of plugins: they have an off switch.

  10. Hi Carrie,

    I disagree with your statement: “Your future self (and other developers who follow in your footsteps) will thank you for separating out your ‘form from function.'”

    I believe your rules apply to themes, and themes, and is in fact a requirement for those services. However, I’m disturbed to widen this as a best practice for ALL themes, and ALL clients.

    Maybe it’s because I come from an agency environment, where we do custom designs, but our philosophy is to avoid plugins whenever possible. They’re too fragile and easily deactivated or deleted. By placing the CPT in a plugin, you’re site’s content is now dependent on that plugin loading. This is worse, in my opinion, than being dependent on the theme.

    Additionally, as a developer, I find it quite easy to copy and past the register_post_type, and register_taxonomy calls.

    I get that it was a pain to switch the custom theme for your client, but it only takes a few minutes to add this code into the new theme or child theme. Right?

    • Hi Paul,

      They’re too fragile and easily deactivated or deleted.

      There’s nothing inherently more fragile about putting that code in a plugin versus in a theme. If you’re working on a client side and concerned about deactivation/deletion, why not make it a Must Use plugin?

      While maybe the separation of form/function is “more important” for distributed code, I think it applies to custom work as well. The project I cite in the post is an example of why it’s not ideal in custom theme. (It’s not just a CPT in this case, it’s a crap-ton of meta data generated by a third-party tool that’s not a matter of copy/paste, but of rebuilding everything on the back-end related to CPT meta. It’s not rocket science, but it’s added quite a few unplanned for hours/cost to the project.)

      I guess there’s always some case that’ll be an exception to the rule, but as a general rule of thumb, I think it stands.


Leave a Reply

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