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:
/* Theme Name: Framework Copy Theme URI: http: //example.com/ Description: Copy of Your Framework Theme Author: Your Name Author URI: http: //your-site.com/ Version: 1.0 */
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:
<div id="wrapper" class="group">
<!--Header - Name of Item Here-->
<header class="group">
<div class="contain">
<nav>
<?php wp_nav_menu( array('menu' => 'Main' )); ?>
</nav>
<h1><a href="<?php bloginfo('home'); ?>"><?php bloginfo('name'); ?></a></h1>
<?php get_search_form(); ?>
</div>
</header>
<!-- End Header -->
<!-- Main Area -->
<div class="contain">
<div id="content" class="group">
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:
#wrapper{
text-align: left;
background: #FFFFFF;
color: #333333;
}
.contain{
width: 960px;
margin: 0 auto;
}
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:
<?php print "\n\n"; ?>
</div>
<?php get_sidebar(); ?>
</div>
<!--Footer Information-->
<footer class="group">
<div class="contain">
<?php if ( !function_exists( 'dynamic_sidebar' ) || !dynamic_sidebar('Sidebar2') ) : ?>
<?php endif; ?>
<p>© <a href="<?php bloginfo('home'); ?>"><?php bloginfo('name'); ?></p>
</div>
</footer>
<!-- End Footer Information -->
</div>
<!--end container-->
<?php wp_footer(); ?>
</body>
</html>
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:
<p class="date"><small><?php the_time('M <\b\r\/> j') ?> <!-- by <?php the_author() ?> --></small></p>
<div class="entry">
<h2><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a></h2>
<?php the_content('Read the rest of this entry »'); ?>
<p class="postmetadata"><?php the_tags('Tags: ', ', ', '<br />'); ?> Posted in <?php the_category(', ') ?> | <?php edit_post_link('Edit', '', ' | '); ?> <?php comments_popup_link('No Comments', '1 Comment', '% Comments'); ?></p>
</div>
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.
header{
background: #fafaed;
text-align: right;
border-bottom: 1px solid #999999;
margin-bottom: 15px;
}
header nav ul, header h1, header form{
margin-top: 0;
}
header h1{
float: left;
color: #08034d;
font-size: 2.8em;
}
header h1 a, header h1 a:visited{
color: #333333;
text-decoration: none;
}
header form{
text-align: right;
}
header form input{
padding: 5px;
font-size: 1.4em;
}
nav{
text-align: center;
background: #333333;
width: 800px;
margin: 0 auto;
}
nav ul{ padding: 10px;}
nav ul li{
display: inline;
padding: 0 15px;
}
nav ul li a, nav ul li a:visited{
font-size: 1.4em;
color: #FFFFFF;
font-weight: bold;
text-decoration: none;
}
nav ul li a:hover{
color: #CFCFCF;
}
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:
#wrapper aside{
margin-left: 675px;
}
#content{
width: 660px;
float: left;
font-size: 1.25em;
}
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
Conclusion
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?
Comments