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.
NOTE: This is not meant to be a tutorial, but rather me sharing my personal style and process. I mention many technical aspects of web development here. If you’re unclear or interested in more detail on anything discussed here, let me know in the comments and maybe I’ll post an in-depth post about it!
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:
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:
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.
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.
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.
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:
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.
In the final post in this series, I’ll cover how I go about preparing my finished theme for release on ThemeJam. Stay tuned…