WordPress Theme Development Process

In the first part of this series about my WordPress theme design process, I covered how I go about the concept and design phase.

This post covers my process for developing a WordPress theme.  That is, after the PSD mockup is complete, this is how I go about coding and preparing to release it as commercial theme on ThemeJam.

First, the markup.

Panic Coda has been my coding application of choice for the past 2 years or so.  A few months back I gave MacRabbit Espresso a try, but it didn’t stick with me.  Coda has everything I need:  A clean interface, user-defined keyboard shortcuts & snippets, and a built-in seamless FTP client.

I start by coding the main templates in valid XHTML and CSS.  I’ve never been one to use a CSS framework or pre-built template created by others (like the 960.gs).  I prefer to make every line of code my own to ensure that every bit is optimized for this particular theme, with nothing leftover that I don’t need.

That said, I have crafted my own “new theme” template, or set of files/folders if you will.  I’ve been tweaking and improving this set of templates over time.  It to speed up the process at the very beginning by covering all the items that I always put in every theme.  My starter template consists of:

• Index.html – blank-slate HTML doc, including the doc type, basic HTML page structure, and a call to the stylesheet.
• reset.css – Created by Eric Meyer, with a few of my own tweaks.  I haven’t always used this in the past, but recently I do.  It’s good for making things consistent across all browsers from the very beginning.
• style.css – This has all of the basic elements of a typical WordPress theme stylesheet, including the theme info declaration at the top.  It includes the clearfix method, basic styles and margins set on the common elements like P, H1-h6, UL, OL, etc.  It also has a few WordPress-specific styles that I know I’ll need later such as some basic comments styles, .alignleft, .alignright, .aligncenter, blockquote, and a few other things.
• Scripts folder – I always include jQuery here.  I realize that WordPress has jQuery built in, but I’m first starting with the static HTML templates, so I’ll need my own copy of it.  I also have the jQuery cycle script here because I use it so often.

With my starter template fired up in Coda, and my finished mockup open in Photoshop, I get to work on slicing and coding up the static HTML template.  My goal here is to get as much of the site structure and details coded as I can.  The things I want to have coded at this stage are:

• Overall structure and layout.
• Typography, including implementation of Cufon (my choice for font-replacement in commercial themes.  For other sites, I go with TypeKit).
• jQuery enhancements.  This includes dropdown menus, featured posts sliders (though I use static content for now), etc.
• Widget styling.  Again, using static content now, but styling the markup to be used later in WordPress.

Most of the time, I’ll do a home page (index.html) and generic interior page (page.html).  Sometimes I’ll create an additional blog page if blog posts will have a unique layout or something.  Usually in website development I would implement a system of includes, like a global header and footer.  However, since WordPress will have it’s own include/template system, I don’t bother creating includes for the static HTML templates.

Browser Testing & Validation

When it comes to browser testing, I always say test early and test often.  Some folks don’t even look at IE until they’re done coding everything.  This is a bad idea, because more often than not, IE requires you to re-think your (perfectly logical) code and you’ll end up wasting time to go back and re-code.

I prefer to test all browsers as I go along, especially as each major piece is implemented.  For example, I’ll get my featured posts slider working perfectly across all browsers before moving onto the rest of the site.

To finish off the static HTML phase, I put my pages through the W3C validator until that refreshing green light appears.

Alternate Colors

Most of the time I implement alternate color stylesheets after doing the static HTML templates, but before integrating WordPress.  I do this so that I can release the static HTML templates as their own product, with multiple color options built in.

The way I do this is simply by creating additional stylesheets, which override specific styles and colors found in the main stylesheet.  Basically, I commit the main stylesheet to being the “default” color scheme, and use additional stylesheets for the other options.  I take very special care in picking alternate colors.  Sometimes I’ll go so far as to pick and implement a color scheme, only to trash it later because I feel it’s not good enough for release.

Time to integrate WordPress

Finally, the real fun begins…

I create a fresh installation of the latest version of WordPress within the ThemeJam demo section (this particular demo is not live yet).  Then I import some basic blog content.  WPCandy has a great “test content” import file you can download and use to quickly fire up a new demo site.  I have created my own version of this, which I think works better to showcase my themes on ThemeJam.

Then I begin creating the theme.  For this, I have created my own personal starter template, which I have named “FrameJam” (Framework + ThemeJam, get it?).  It’s not meant to be a WordPress Framework in the common sense of the word.  Really just a starting point for my own personal use.  Included are a few things I like to have across all my themes:

• The ThemeJam Options panel – with basic options included.  I’ll add more options specific to this theme a bit later.
• Various SEO markup and template tag enhancements.
• Some PHP functions I always use – like images and thumbnail handling, registering widgets, a custom widget template, custom comments markup, custom excerpts, etc.

I duplicate FrameJam and rename it to the new theme name.  Then I overwrite the entire style.css file with the one I created earlier for the static HTML templates.  Now we have basic styling, but the markup isn’t together yet.

I go line-by-line integrating WordPress tags and functions with the markup I already created earlier.  It’s just a matter of pasting chunks of markup from the static HTML templates into the WordPress templates.  I start this process by setting up header.php, index.php, and footer.php as these 3 templates will basically create a full page from top to bottom.  Then I’ll fill in the rest of the template files.

Now is a good time to re-test everything across all browsers.

The last phase of WordPress integration is to implement all of the theme options.  This adds an additional layer of template tweaks, turning static things into variables, adding inputs and sets of inputs to the Theme Options page, and whatnot.

Then of course, there is testing, testing, and more testing.  TIP: Test at night, but test again in the morning when you’ve had a good nights sleep.  You’d be surprised how many things you miss when you’re bleary eyed.  There are so many little things that go into a WordPress theme, it can take a whole week just to tie up all the loose ends.

That wraps up the wordpress development phase.  If you have any questions for me, or if you have a different approach you’d like to share, please leave your thoughts in the comments.

Next up…

In the final post in this series, I’ll cover how I go about preparing my finished theme for release on ThemeJam.  Stay tuned…