When it comes to WordPress theme development, one or the areas that developers often find themselves wrestling with is just how verbose they should make their code.

For example, we’re often taught and strive from principles such as DRY and KISS, but it’s hard to maintain both of these when building WordPress themes from the ground up.

For example (and as according to the Codex):

At the very minimum, a WordPress Theme consists of two files:

– style.css

– index.php

And for anyone who has done extensive work in WordPress development knows this to be true; however, if you’re getting into theme development – that is, specifically for bloggers, or digital publishers – then you know there’s a wide variety of templates that are also supposed by the WordPress Template Hierarchy.

To name a few:

  • style.css
  • rtl.css
  • editor-style.css
  • archives.php
  • author.php
  • category.php
  • comments.php
  • date.php
  • index.php
  • single.php
  • tag.php
  • …and so many more

But here’s the deal: it’s nearly impossible to embrace DRY while simultaneously trying to implement each of these templates.

Instead, we’re left with having to repeat a variety of code all the while doing so when much of the code could be produced though template parts and conditional logic.

Though I’m sure we all fall somewhere in between on this issue, he’s where I’ve landed with respect to the various themes that I’ve developed over the last couples of years.

WordPress Theme Development: The Blogger

First and foremost, when it comes to building WordPress themes, you need to think about the various people in your audience. The fancy term for this is the market segment, but the truth is that users can usually be divided into at least one of three groups:

  1. Bloggers
  2. Designers
  3. Developers

Naturally, there is some overlap between the designers and the developers.

Anyway, this is where the choice on how to structure your theme comes into play.

If you end up building a theme primarily for designers and/or developers, then you can most likely get away with building a theme that uses a variety of conditional statements in `index.php` with a few partials (thanks to `get_template_part`) to make the entire blog function.

No problem, right?

But let’s be honest: The majority of the audience for themes are going to be people who want to blog in some form or fashion. This comes in terms of sharing long form articles, tumblelogging (or, in WordPress-world, heavy use of post formats), sharing photos, videos, and so on.

In short, it’s people who want to share content.

To that end, how the theme is built doesn’t matter as much to them as long as the theme looks good (which, I know, is subjective), helps them achieve the things they want to get done, and it looks good to search engines (let’s face it – everyone wants their site to look good to search engines), then you’re good to go.

Let’s Not Kid Ourselves

People love to tinker – if they find another font they like, they want to use it. If they find another color they want to use for part of their site, they will.

And the blessing and curse of open source is that they – like us – have the ability the modify the core code of their product to fit to their liking.

Why

But just as we – as developers – know that we should never touch the core code, we’ve done a poor job evangelizing this to our customers in the theme marketplace about our own work.

Remember: view the theme as the core product and child themes as those customizations.

Sure, some people offer up a `custom.css` (and I’ve been guilty of this at some point), but as soon as a new upgrade appears for the theme, those changes will likely be overwritten or simply made irrelevant if the elements that they alter are to be changed.

Think of the Children!

So here’s a dilemma that I’ve been faced with while building Mayer: I want to make sure that I have as strong as a theme as possible.

First, I’m targeting the theme to the following audience:

For the established, frequent, long-form bloggers, and for those who aspire to be.

Easy enough, right?

Sure, I could go on about typography, readability, and all of that stuff, but what’s the point if those things are not only subject to change, but are going to be visible in the demo?

Secondly, I’ve gone against the grain of trying to keep it DRY and have implemented a number of different templates. These include (but are not limited to):

  • 404
  • attachment
  • author
  • category
  • comments
  • content
  • date
  • header
  • index
  • page
  • search
  • searchform
  • sidebar
  • single
  • tag
  • …and more

And the reason is because I know that inevitably someone is going to want to modify the theme to fit their liking. And that’s fine, but I want to make sure that I’m setting themselves up for success.

The way to do this is to think of the children – specifically, the child themes.

If the templates are defined in the base theme – rather than, say, a bunch of developer-ish conditionals – users are going to have an easier time basing their templates off of something that already exists.

On top of that, even though the code is a bit repetitive, it helps to know exactly where I need to edit should (read: whenever I notice) a bug arise.

But that’s the content for another post.

Keep It DRY, Except Not This Time

So if I had to sum this up in some concise way, I’d say that I – like many developers – want to keep my code as DRY as possible, but there’s a tradeoff that comes with doing so in the context of WordPress theme development.

And I don’t think that staying DRY is the best way to go about it if you’re going to be marketing a product to a wide audience.

I’ll likely talk about this more in the future as it relates to other personas, but that’s my general stance on it, for now.