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

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

Tutorial Details
  • Platform: WordPress
  • Difficulty: Beginner - Intermediate
  • Estimated Time: 45 - 60 minutes
This entry is part 4 of 4 in the series DIY Theme Framework

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?


Other parts in this series:DIY WordPress Framework Part 3: Using the Framework as a Child Theme
Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • http://luetkemj.com luetkemj

    Fantastic series, I’ve been working on my own boilerplate for a while. Great suggestions and things to think about!

  • dj

    I enjoyed your series – I do still have a couple of questions which confuse me, however; not with just this boilerplate, but I’ve seen others do it too. FIRST, perhaps I’ve just not thought it through enough, but what is the difference with styling a whole new “wrapper” division layer vs. just styling the <body> tag? I’ve seen some templates styling the <body> which seems to accept all the same kinds of attributes that one would apply to a <div id=”wrapper”>. In this case the “wrapper” only has background color, type color and text-align, and one usually has internal “wrapper” divisions which can handle the “auto” margins as needed.

    Is there some substantive exclusion the body won’t provide in styling or some other “best practice” issue I’m missing? If so I’d appreciate learning; but, if not, it would seem that basically pushing every single element yet one layer deeper in the DOM cannot be a good thing – especially in light of Google’s new SEO rules rewarding for load times and the recent tendency toward the use of complicated “child” and other “relationship” selector types which adds complexity to DOM handling.

    A SECOND issue I had hoped you would have addressed is your decision to continue to use the 960 screen size limitation in light of your use of 100% width on headers and footers. I mean I totally understand the readability issue for blocks of content which are too wide AND I do understand the aesthetics of the full width headers and footers – they just look better don’t they; but, I’ve never understood why many designers seem, to me at least, to be oblivious of wasting so much real-estate above the fold on otherwise capable monitors. Additionally, from a “boilerplate” standpoint, it would seem much more appropriate to have additional content divisions (i.e. hot links, previous posts, etc) take up any extra space and fly them to other positions using “@media” contingent upon smaller screen size (see Chris Coyers new site). If you had that capability built into the boilerplate it would be much more simple to delete what you didn’t want than to add it in when you could use it. You did say it is a “work in progress” – perhaps, a followup tut is possible.

    Not being an active developer, perhaps there is something that I don’t understand about it, so would appreciate any enlightenment on the matters.

    • http://ecustom.ca DamonB

      Hey dj,

      I’m pretty sure Joseph is not approaching these tuts from a stylistic standpoint. By that I mean, he’s not trying to show us best practices for styling or anything, but rather showing us how easy it is to work with WordPress, and giving us a framework to do that upon. If this was a tut showing us how to specifically style a mockup or design, I have a feeling that Joseph would apply styles not only for 960px screens.

      Regarding your point with body vs. wrapper, I always style my body with a background colour, then use my wrapper for a sticky footer. Since I use the 1140 grid, with some enhancements, I just work from there.

      Cheers!

    • http://www.casabona.org/blog/ Joe Casabona
      Author

      DJ,

      Thank You!

      DamonB is more or less correct on my sentiments regarding the scope of the article, body vs. #wrapper, etc.

      For the page width, I do still use a 960px width because I’m unsure (more like unconvinced) that going wider is a good idea. 14% of w3schools traffic is still on a 1024px resolution and w3schools visitors are usually ahead of the curve. I do think that this would be an interesting discussion to have, either here or on webdesigntuts+.

  • http://www.windkr89.nl Erik

    Great series! Is it possible to create an ebook from it? (and make ik available for Premium members of course ;)).

  • jkk

    Thank you Joe for this wonderful tuts. I just have a question: when creating a wordpress framework, how can you set it up so that you can use when website has two-sidebars (and content middle) or one-sidebar-left-and content or right-sidebar or any combination.

    Basically I am asking what code to use to enable the framework so that I can switch design easily.

    Also is your series (coming up) included the Options page lesson(s)?

    Thanks in advance.

  • Pingback: Best of Tuts+ in November | Graphfucker

  • Pingback: My Stream » Best of Tuts+ in November

  • Pingback: Best of Tuts+ in November | linuxin.ro

  • Pingback: Best of Tuts+ in November | Shadowtek | Hosting and Design Solutions

  • Pingback: Best of Tuts+ in November | cssWOW Showcase | Css Gallery | Css Awards | Design Inspiration Tutorials

  • Pingback: Best of Tuts+ in November : Ahmad Assaf`s Blog

  • Pingback: Best of Tuts+ in November | Pro Sound Central