There’s lots of information available on WordPress’s codex about how to create themes for your blog, all of it dealing with the filters and actions you can use to manipulate the active content on your blog in cool ways. It goes without saying that those are important pieces of information, and in fact there are some outstanding tutorials for putting together a theme that you should definitely check out. WPBits is one such resource.
But I’d like to talk about some concepts that happen before you get to the active content: the HTML, and how you go about designing a theme which has to exist in all those varying pieces yet all go together to create one cohesive whole. This is a very high-level tutorial, meaning that specific details will be omitted in order to introduce the most basic concepts. I’m writing more about the workflow than about the process, if you follow me!
First of all, while anywhere can seem like a good place to start, working with themes is probably not the best way to hone your HTML/CSS skills. There are a surprising number of moving parts that make up a WP theme, and I am continually surprised by the extra things I need to add to my CSS to make things work. So, having a good, solid foundation in HTML is definitely a prerequisite to creating an effective theme.
Moreover, while WordPress themes are in fact quite a bit simpler to work with than some other templating systems I’ve worked with (phpBB, eh-hem), its easy to get lost when spanning several discreet files. That leads to ugly, non-compliant code, and you don’t want that.
So with all that said, the first and most important first-step task in building a theme is building one static HTML document that looks the way you want the resulting website to look. Depending on the complexity of what you want the final product to be, it may require you to build more than one static page. You may need to make one for the home page, one for a posts list, one for an individual post. But the important thing is to make sure all pages work off the same CSS file, and all pages use the same basic layout, that your <head> information and the top of the pages are the same.
You’re going to need to simulate active content on the page with some dummy information, of course. You could use any text you wanted for these things, including the classic Microsoft Greek filler content (Lorum ipsulam yadda yadda). However, I find it more helpful to use the text as labels for what will ultimately go into each slot. Just go ahead and drop some silly pseudo-titles like “This is a post” where your post titles would go, along with “this is the post body” repeated over and over again in what would be the body of the post. Labeling your content areas helps you when you go to add active content, and in the meanwhile, text in your content areas helps you figure out your borders, margins and padding.
Once you’ve got those pages working more-or-less correctly (changes are inevitable, so don’t beat yourself up too much), the next step is to use a validator to check those pages for XHTML compatibility. Not everyone cares as much about such things, but if you’re planning on Google and other search engines indexing you correctly, it’s helpful to make sure your site conforms to a schema that is predictable to their bot programs.
When choosing a validator, it make sense to just stick with the W3C’s validator. They made the guidelines, and we presume that their validator will comply with those rules. Not all validators get it right.
Once you’ve validated your code, the next step will be cutting the file up into it’s requisite pieces. Again, don’t stress on adding the active content to the template yet. If the files don’t come together as a complete whole without the active content, there’s not much sense in going any farther.
For this article, I’m not going to get into too much detail about precisely what you want in each file. There are other tutorials out there for that, and besides, this again is a very high-level tutorial. However, as a refresher, the header.php file generally includes all of the <head> information and also the top of the visible page. The index.php file will include “The Loop,” which would be where your posts and page content would appear. The sidebar.php file includes your sidebar content and your footer.php includes the last bits of the visible page along with any additional JavaScript file includes you might find necessary.
But if you simply break the file up intuitively, copying and pasting from the original doc to new files, you should be able to then package those files up with the CSS file, upload it to your server, and use it like any other theme. Of course at this point, there won’t be any actual posts in your theme, just your silly “This is a post” content. That’s fine. The point is to compare the results to your original layout. It’s also a good idea to recheck the doc with an XHTML validator, just in case you’ve inadvertently messed up some nesting or something like that.
Now that you’ve accomplished all that, you can begin adding your active content. The nice thing about this is: you’ve satisfied yourself that the template works the way you wanted it to, so any further problems from this point on are purely about what you’ve added for active content. What’s more, WordPress content is not going to mess up your standards compliance, so while it’s good to check the validation every once in a while, it won’t be the content that is the problem.
I hope this helps people begin to think about the best workflow for them when creating a theme. Attacking a project such as this in an organized fashion is the best way to achieve your goals. This is the first tips post to this site, but I’m hoping to get more into granular details in the coming series.
