1. Code
  2. Theme Development

DIY WordPress Framework Part 4: Using the Framework as a Boiler Plate

Read Time:8 minsLanguages:
This post is part of a series called DIY Theme Framework.
DIY WordPress Framework Part 3: Using the Framework as a Child Theme

Last time we used our framework as a child theme, creating a totally new theme that depends on the framework. Today we're going to use our framework as a boilerplate, copying the folder and making edits right to it.

Now some people might question the reasoning behind this, and that's fair. Why would we change the framework itself? My original intention for this framework was actually to be just a boilerplate- something that I could copy, paste, and modify- a la the HTML5 Boilerplate. Because of this, most of the time I use my boilerplate, I actually just copy and paste it.

There is also some merit to this method. If, for example, you're dealing with a very different design structurally, you'll end up rewriting most of the template pages anyway. The main reasoning behind me creating the framework was to reuse my CSS and more common functions. It just followed suit to create a header, footer, index, etc. to get the theme working. While I did try to make it as generic as possible, I also wanted to keep it lightweight. Because of that, there isn't an engine to inject code into various parts of the theme like in Themaic or other bigger frameworks, which I prefer. As I said in Part 1, I didn't want to create a whole new API for people to learn when there is already the WordPress API.

Getting Started

Before we get started, we should outline some goals for using out framework as a boilerplate. The first is that we should only change files that need to be changed. Remember, outside of our header and footer we tried to make the other pages as generic as possible. That means if CSS can be used to arrange what's already there, we might as well use that since it's less work (edits-wise) for us. We should also be mindful of what's in our theme files. We have 2 widget areas (one in the footer) and a few functions designed for reuse. We should utilize those if we can. That being said, here's a little reminder what what we're starting off with:

Our Framework

First thing's first: let's copy and page our framework and prepare it for use. I just copied my /wp-boilerplate/ folder and renamed it /wp-boilerplate-copy/ (there I go again with the creative names). As always, we'll modify our style.css file:

Remember, we don't need the template line this time around because this is a direct copy of the framework.

Structural Changes

Before we dive into the CSS, let's consider what structural changes we want to make. I'd like to do a few things to the overall design of the site. The first is place the navigation above the site name and search bar (which we'll also add). I'd also like to make it so the header and footer bars extend the width of the user's screen, while keeping the content at a set width of 960px. This is the final product we'll be working towards:

Our Final Product

What we'll do next is modify the header. Here is everything in header.php after the <body> tag:

You should notice a couple of things. I changed the main container ID to "wrapper" and added a "contain" class. This is so that we wouldn't confuse the two. The #wrapper is still applied to the entire page, but since we want the header and footer to extend the entire width of the user's screen, we need to remove the width definition. However, since we still want the actual content kept to our original 960px width, we need to create a separate class that we'll use for several content sections. Here is what the CSS looks like for #wrapper and .contain:

As you can see, we've moved the information pertaining to width and alignment to .contain. We'll now modify footer.php to match header.php:

You can see that in addition to matching up our divs from header.php, I also added a .contain div around our footer content. I also moved the sidebar to the footer. As some of our readers pointed out in Part 2, this is a bit more SEO friendly.

Now that we've modified the main structure of the site, let's take a look at modifying one of our template pages.

Modifying Template Pages

We actually aren't going to do too much here. I just want to make one small change (code-wise) in index.php. In the loop where we place our title and date:

Here, I've reversed the title and date lines and assigned the class .date to the paragraph with the date info in it. I also put all of the post info within the .entry class. That's so I could create a little date square for each post, to the left of the post.

Note: As I've mentioned before this is a living project, constantly changing. In future builds I will likely keep the date class in so I can more easily style that section.

Our Date Square

The rest of my planned changes we can do with CSS because of how the pages were coded (which I'll talk about in the next section). However, using the framework as a boilerplate let's us more easily make changes to our theme than does a child theme when it comes to rearranging or recreating certain templates.

Styling the New Theme

Now that we've made our structural changes, let's take a look at some of the CSS. I'll highlight the important parts here. All of the CSS is included in the theme files that accompany this post. First, let's take a look the CSS for our header, which went through the biggest transformation.

Here you can see we've applied background colors and font stylings to our header elements, as well as some strategic placements. Our result is a vastly different header than the one from our original framework's.

Our New Header

The other part of our CSS I wanted to highlight here was how I 'fixed' the sidebar:

As you know, our CSS was more or less here for this section- we just had to take the inverse of what we had since we changed the order of our code. Clean and fairly simple!

The rest of the CSS is pretty straight-forward, and as I mentioned, included in the source for this post. I changed up the post CSS and applied some default styles to our HTML tags regarding color, sizes, and padding/margin


I wanted to conclude this series by weighing the merits of this method vs. creating a child theme, since this post was more of a proof of concept post (doing the full theme would run really long, but I could do a more in-depth one if it's requested). I would say that the copy-and-paste method would be best if you're making major changes to the framework. You still get the code we laid out, but you'll spend less time rebuilding what we've already build in a child theme. While we made minor changes here, we may come across a design that requires us to change multiple pages and having the base code there already is a big help for both reference and reuse. I generally go the copy-and-paste route since I try not to make all of my designs look the same.

What about you? What do you see yourself doing more?

Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.