DIY WordPress Theme Framework Part 1: Defining Your Needs

One of the best things about my education at the University of Scranton was the recurring lesson we learned about reuse. Reuse is incredibly important in programming for many reasons: easier testing, saving time, the ability to focus on more advanced things, etc. Once I graduated and entered the wonderful world of full-time freelancing, I decided if I was going to keep doing WordPress work, I would need to apply those reuse lessons to my everyday life. Number one on my list was a simple WordPress theme framework.

The first article in this series is going to be a little different from other ones on this site. In this article I want to communicate to you some of the lesson I learned about reuse and defining your needs. I will be providing my framework to you in the next article, but it’s a fact that everyone codes differently and what I provide might not suit your needs best!

Some Principles of Reuse to Keep in Mind

Anyone with formal education in Computer Science or Software Engineering can attest to the fact that there are countless theories, libraries, and classes (programming classes, not school classes) dedicated to some very advanced forms of reuse and generic programming. While I think those are overkill for a theme framework, there are some principles I tried to follow when creating mine:

“Testing will ensure your code works before implementing it 5, 10, or 20 times.”

• Design Your Code: I know when talking about WordPress, design usually implies the front-end design, but it’s just as important to design the code. Lay out what your functions, classes, and pages will be before you start to code them up.
• Generalize When Possible: Possibly the most important principle is to recognize when you’re reusing code snippets and to generalize them into functions. This will make managing and updating your code much, much easier.
• Document and Test Thoroughly: This is something you should do with all code, but especially code you plan on reusing frequently. Documenting will help you remember what you were thinking 6 months or a year down the line. Testing will ensure your code works before implementing it 5, 10, or 20 times.

Define Your Needs

Now that we’ve laid out some things to keep in mind, we need to define what we want our framework to accomplish. Remember each of us has our own needs, and while I’m going to talk about mine, yours may be different. My needs were fairly simple at first: I wanted a simple framework that did my initial work for me.

While creating WordPress themes for my clients, I noticed my process was the same: copy K2 (the default theme at the time), remove the stuff I didn’t want to use, replace it with my code. A lot of my code was similar: the same CSS reset, the same CSS structure, the same style header, navigation, etc. After a while, I found it was easier just to copy my last client’s theme and build off of that. It was then that I decided to build my own framework.

“We need to define what we want our framework to accomplish”

With that decided, I needed to define my needs: what was I doing over and over again, and what could I generalize. My list of requirements was as such:

• Plugable CSS: There are several parts of my CSS that rarely changes. This includes in WordPress class definitions, my CSS reset, some general classes I use (.hide, .left, .right, .clear, etc), and (usually) my IE Fixes. If I could abstract that all away, all I would need to do is dump in a site specific CSS file (called master.css after Dan Cederholm’s simple CSS framework) and I know everything else would work properly.
• Constants for the Theme URL and Image Paths: These are 2 variables I need with every theme. If I could easily define them somewhere, I wouldn’t need to worry about replacing the URLs for every site I create.
• Common WordPress Functionality: This is the menus, sidebar definitions, and anything else I could think of that I’d be typing over and over again.
• Generally Defined Template Pages: The common theme pages (header, footer, index) with enough on them to make them useful, but not so much on them that I’d have to really change theme every time I developed a new theme.
• Common Folders: I always have an images folder, css folder, and css/img folder. I had to include these too.
• Lightweight: It’s got to be lightweight. I don’t want to have to sift through pages and pages of code to find what I want. My though is that WordPress itself is a complex framework; why build a second complex framework on top?

I also wanted to build some function for features of several pages, like the “page not found message” and the posts page navigation. This goes back to the mentality that a single function will help me more quickly change multi-page features.

See What’s Already Out There

The great thing about open source software is that if you need something, it’s probably already done. The same thing goes from Frameworks. There are dozens of frameworks out there, so before you go off to develop your own, it would definitely be worthwhile to checkout what’s already there. The purpose is to save time, right? No better way to save time than to not have to develop at all!

Thematic by ThemeShaper is a very popular framework

To help you out, I’ve compiled a short list of frameworks I’ve at least looked at (though most of them I have actually used):

• Thematic
• Thesis
• Carrington
• Genesis
• Atahualpa
• From the WordPress Codex

While exploring these frameworks, keep your requirements in mind. Test these properly: download, install, enable. Then try building a child theme and playing with the settings. See what you find. Then make your decision.

For me, I felt the ones I tried were too complex and not lightweight. They are great for people who need a theme quickly but as far as customizing goes, I had to learn a whole new system in order to build themes. Like I stated earlier: I already know WordPress’ complex framework/API. I’d have to replace that knowledge with another theme’s framework/API. I decided to build my own, which would still use WordPress’ functions, not replace them.

Conclusion

I’m sure you could have guess at the outset of this article that the inevitable conclusion would be that we build out our own framework. We’ve got our principles and requirements, and we’ve done our research. We’re ready to build a framework, which we will do next time!

The last thing I invite you to do is chime in on what I’ve said here: what are your principles and requirements. Do you use one of the frameworks I’ve mentioned here, or have you already developed your own? Let us know!

In the next session in this series, we’ll be applying these principles to the first day of work on our new framework!