Unless the theme has a rock solid upgrade capability built in… i’ve yet to see one that does… the more features that are built into it the more of a pain in the ass it is going to be to apply bug patches when they are needed.

Themes on the other hand are not so simple to update. Themes are designed to be hacked away by the user if they so desire… building functionality into the theme makes this impossible as it eliminates the capability of doing updates to the functionality.

The utopian scenario is a parent/child theme setup where you can upgrade the parent without impacting anything. But good luck getting the average users NOT to edit the parent theme directly. As soon as they do, it makes upgrading pretty much impossible without losing their changes. That results in pissed off users, even if it is their own fault.

Plugins are designed to be updated frequently because the more complex the functionality, the more bugs and the more updates that will be required. They are designed to handle this.

With plugins, the user doesn’t typically edit the plugin. They can quickly and easily receive updates and fixes via the plugin automatic update functionality.

That is what plugins are designed to do.

I see both points of view

This is really all I’m saying. There’s more than one point of view here and it’s going to be based on who’s using WordPress. There’s no question that if you want to change themes, while keeping all your functionality, it makes more sense to have that functionality be coded as a plugin, but is that how most people are using WordPress. Often a change in theme means a change in functionality too.

When clients approach me to develop a theme they don’t ask for functionality. They tell me they want a theme with a calendar. To them that calendar is part of the theme. The see it as part of the design. Later they come back to me wanting a new theme because they don’t like how the calendar looks or they want a theme that has social media links instead of a calendar. The average user of WordPress doesn’t necessarily see the difference between theme and plugin.

Other clients might come to me looking to have me customize a theme they found. Often they chose the theme, not because of the layout or color schemes, but because it included the calendar they wanted. Again they see everything as the theme and not necessarily a mix of theme and plugin.

The above is not typical of everyone, but it is typical of a certain class of WordPress users.

You can reduce all your WordPress files to be nothing, but a bunch of hooks and widget areas and a css file to style everything. That would make your theme very flexible. It would also confuse the majority of WordPress users who’d be wondering why when they installed the theme it didn’t look like the demo they saw. Are they going to use your theme that requires them to add plugins and widgets or are they going to use the theme that looks pretty much like yours, but has all the functionality built in by default?

I think Christina is exactly right in saying

that the future of WordPress is shaping up to be less about everyone change themes like they are socks and more about what Drupal is doing, which is to package different distributions around a certain concept.

I think you’ll see more themes developed as turnkey solutions for a specific industry. As an example think of a photographer who wants to use WordPress mainly to show off their portfolio and have image heavy posts. That person will need to have all sorts of image gallery functionality, etc. that right now exists as a plugin.

Some theme developers will create a design and bundle it with those plugins. Other developers will put the functionality directly in the theme. Like it or not the theme with the functionality built in is going to be the easier one for most people to use and is going to be the one that gets recommended more often by those people.

Again that’s not necessarily true of everyone, but it is true for a large group of WordPress users.

When someone using that theme wants another look for their site they’ll come back to the place where they found the theme and discover a series of skins (a new css file? a child theme?) that exist to change the theme’s look.

Again I’m not arguing that it doesn’t make sense to code the functionality as a plugin instead of placing it directly in the theme, but it does add one more level of complexity for end users and one more place where they can make a mistake.

Don’t Make Me Think.

Those of us commenting here don’t have to think about adding a plugin. The average end user of WordPress still does. Ultimately our goal as theme or plugin developers is to make their lives easier. For some that will mean coding functionality directly into the theme and for others it means separating the functionality into a plugin to make the theme more flexible.

Decide who you’re developing for and code accordingly.

As others have stated, particularly Bill, Steven and John — the more things that the user has to install to get stuff to work — or the more things that have to be updated, the more hassle.

Case in point. I tons and tons of staging sites on my MAMP server running on my Mac. This way I can have a million different installs of various things and keep trying stuff out, breaking stuff, etc. However, I also like to have a mirror of my current sites, for development purposes. When it comes to creating a local mirror, I have to install WordPress, upload my themes and plugins that I use on my main sites over, activate them, make sure the settings are set correctly, etc., just to get to the point that I can have a good mirror. Now, granted, I can (and often do) just import in the MySQL file and mirror the databases, but even so, if I’m setting up a new testing environment, it’s a lot of work.

And that’s just for one theme. You add in other stuff into the mix, and it just grows from there.

Plus, what happens when the person who made your really awesome contact form disappears off the planet. Or your plugin for a certain graphical element isn’t updated and breaks in future versions. My point is — for stuff that you see visually, I think it does make sense to build it into the theme when possible. Sure, make it an option to turn it off or to override, but build it in so that the out of the box experience doesn’t suffer.

When it comes to stuf like SEO, Google indexing, and other backend components, I’m a little less sure. I think building in a option for a feedburner URL or adsense code makes sense, those plugins are typically just injections into the header files anyway — but for more in-depth stuff, it might not make sense to make it all about the theme.

Really though, I think that the future of WordPress is shaping up to be less about everyone change themes like they are socks and more about what Drupal is doing, which is to package different distributions around a certain concept. So you have your Thesis WordPress distribution that is your whole site in a box. And you can edit the CSS and other stuff and you can add things to it but the theme becomes a fundamental part of the backend, not merely a component. That’s how real content management systems work and if WP moved in that direction, it would be a good thing.

Themes should be designed to be universal with no strings attached.

That way everything you need is bundled, plugins within themes can be upgraded separately from the theme as a whole using the normal process, an alt version can be released, or simply created by the user, and maintained separately so theme updates don’t break the update.

What else could you possibly want?