Seamlessly Integrating a Custom WordPress Blog Template into Your Website

When I first decided to re-launch this website, I had a few goals in mind.  I had been preaching and practicing the virtues of clean code and separation of concerns with the back-end code of the projects I was working on, and wanted to apply the same ideals to my front-end design as well.  While that certainly is easier said than done sometimes, the control freak in me was ready bang out a new custom site template that keeps as much of the aesthetics and presentation information as possible in CSS, and all UI behavior wrapped up into script files, leaving a nice, clean, and minimal HTML5 layer for the actual content.

Of course, what’s a website without someone yapping about something on it?  The site definitely needed to incorporate a blog so that my self-worth as a vanity domain name owner could be justified.  But a blog template?  Something I didn’t have a hand in creating and can’t control myself?  That sits about as well with me as a plate full of sushi and Jell-O, so I knew I had to embark on a mission to customize one to work with my site, and not just be tacked on with some digital duct tape.

I enjoy the product and community surrounding WordPress and recognized the potential for customization once I really started to look at the guts of a WordPress template.  I was also able to find some good pointers from others who have done the similar task of trying to make a WordPress template to fit into the look and feel of an existing site.  But taking that idea a step further, I didn’t simply want to create something that mimicked my site design, I wanted something that actually used my site design.  For example, if I needed to change a column width, modify the look and feel by changing colors on a bedrock CSS class, or any other shared characteristic of the design, I wanted this to apply to blog pages the same way it would apply to any other non-blog page of the site, without any extra lifting.

Sure, the WordPress template is made up of many, many files that live separately from all the other content of your website, and those files tend to be littered with some wacky characters that represent the PHP code that makes the blog function – and can quickly scare off non-developer bloggers.  And, yes, those template files point to a huge pile of CSS themselves, which can be unsettling when you start to think about allowing the new scary CSS kids on the block to play freely with your polite and well-mannered CSS babies that you worked so hard to raise!  There’s bound to be schoolyard fights once you get them all in the same confined space, right?  But, ultimately, there’s no reason WordPress template files can’t utilize the same resources that your non-blog pages do, and nothing stopping you from adopting WordPress’ CSS styles into your household and teaching them how to play nice with the other children.

Below, I will recount the most important aspects of this journey, to help along anyone who may find themselves looking for the same level of customization on their site’s blog.  WordPress is a great product, and so long as you are careful about a few key aspects, you will find customization to be completely doable.

1. Know your site before you start
It seems like this goes without saying, but the point here is that you need to understand the makeup of the site you’re customizing for before you get started.  If you created the whole thing yourself, then this part is easy.  If you’re doing work for someone else’s existing site, you’ll want to know where all your resources are (and how the pages of the site use them) before you start, perhaps even by creating a local snapshot of a single page, if that’s all you can get access to.  It’s important to know how to consume them if you want your blog to look like the rest of the site.  You could create all localized copies of image, CSS, and script files specifically for the WordPress template, and your end product would still look fine, but that doesn’t quite satisfy the maintainability I was looking for.  If I change my site’s bedrock, I don’t want to have to change it in two (or more) places.  So my approach was to have my WordPress template use the same resources that all the other pages of my site use.  If you have that level of control over the whole site’s design, then this is the best way to go.

2. Copy a WordPress template and make it your own
When you install WordPress, you should have at least one template installed in the wp-content/themes folder (in my case, the template “twentyten”).  Simply duplicate that folder and BANG! new WordPress template!  You, of course, want to distinguish it from the original, so open the style.css file inside of it, and modify the meta data in the comments at the top to give it a new name and new details.  You will see this template and these details available to you in the WordPress dashboard.

3. Update index.php to be your own
Now that you have your own template to work with, it’s time to customize it.  There are a number of .php files in your template that you need to work with, but the most important is index.php.  When you look at this file, all you really see are a few PHP tags, and maybe a little extra HTML to help display them.  The piece you want to zero in on here is known as THE LOOP, and it’s the php tag that provides most of your blog functionality.  You want to turn index.php into a page that represents your site’s “slice,” so copy in all of the HTML that your normal pages would use, but take caution to keep your PHP Loop tag intact, and placed into the main content area of your design, as this is the piece that will be populating your blog articles and content.  You’ll also want to at keep <?php get_sidebar(); ?> and place that into the sidebar area of your design, as this is the primary navigation that is available to your readers.  Once you have replaced index.php, you should be able to test it in a browser and see blog content in a page that looks (mostly) like your site.  If you are including your site’s custom CSS in your template, you may at this point start to notice places where WordPress’ own styles are conflicting with yours.  And if you start clicking on some of the links under a blog post, you’ll see aspects of the template you’re copying come through.  You’ve got some more work to do!

4. Slice it up!
You’ve got a good start, but need to fill in the gaps.  In order for everything to flow well when a user navigates your blog, you need to slice up your index.php into header, sidebar, and footer .php files.  This will entail moving most, if not all, of your HTML out of index.php altogether, and into the supplementary files, and replacing them with simple <?php get_…> tags referencing those sliced bits which are pieced back together when the different aspects of your blog are viewed.  Familiarize yourself with the contents of these three .php files before adding in your HTML pieces, as you may or may not want to keep all the PHP tags that exist in them by default.  For my purposes, the header.php and footer.php files I wanted to be completely custom and didn’t care about retaining any WordPress links, so those files became strictly the HTML slices of the top and bottom of my starting index.php, with no php tags being retained.  However, the sidebar.php file includes vital php tags that provide the primary navigation for your blog, so I left all that intact, and only added a small amount of sliced HTML that closes up the main content area of the page that precedes the sidebar area in my design.  This is where my nice and tidy HTML5 site design really shined through.  Everything was already well modularized and clean before starting, so porting to a template became that much more intuitive.  When finished, my index.php was whittled down to nothing more than four php tags, and looks like this:

<?php get_header(); ?>

<?php
/* Run the loop to output the posts.
* If you want to overload this in a child theme then include a file
* called loop-index.php and that will be used instead.
*/
get_template_part( 'loop', 'index' );
?>

<?php get_sidebar(); ?>

<?php get_footer(); ?>

5. Final thoughts on clean design and maintainability
Once you have your index, header, sidebar, and footer.php files sliced up well, they can be used by the numerous other .php files in your template that already reference them in the same way.  Take a look through some of them to further familiarize yourself with the process (for instance, open category.php to see that it also references your header, sidebar and footer files).  You’re now in a position to add additional non-blog content to sit side-by-side with your blog content whenever you feel a hankerin’.

I mentioned before that the clashing of CSS can be a very real problem, and wanted to close with a few words about how I handled it.  Since I control my own header.php file, it contains links to the same CSS and script files in the HTML header that the rest of my site does, and so if I change anything in those resources, it applies to all pages, blog or otherwise.  But in replacing the header HTML completely with my own, I lost the link to WordPress’ own style sheet which includes all the CSS meant to style up your blog content, and this content could look a little sad without that.  So one final step that will need to be done, in order for you to have the look you want in addition to the functionality, is to reintroduce the WordPress styles, and to selectively remove anything from it that clashes with your own bedrock styles.  This exercise will be unique to everyone’s site design, but if you have a clean CSS structure to begin with, then it will be clearer to you what can stay and what can go from the WordPress template’s styles.css file.  For my purposes, I simply made a copy of that file, referenced it from my template, and removed just about all of the styles meant to set up layout (since that’s all done by my own custom CSS) leaving behind only the styles for presentation of the blog content.  These sections of CSS were well commented in styles.css, so it was easy to digest the very large style sheet, and the sections I ended up removing were Reset, Layout and Structure, along with small piece of Global Elements that was setting body background color and a slight addition in Widget Areas where I decided to up the font size of the headers in the side menu.

All in all, it was a great exercise for customization, and the control freak in me got exactly what he was looking for.  I do believe this is something that can be achieved by any site designer, whether you know PHP or not, and demonstrates how clean design, with separation of concerns, not only gives you a great foundation for maintainability of your site, but also for extensibility.

Have it your way!

AR