5. Our First WordPress Website

In the preceding four chapters we covered WordPress basics. From this point on, we’ll build on those skills while developing a theme. The J2 WordPress theme was designed specifically for this book to cover the most vital aspects of WordPress theming.

What you’re about to learn

• Our plan for theme development

• Theme design best practices

• How to differentiate between content and how it will be powered

• Basic template file and site architecture planning

Design Recognition

Before we jump in, I’d like to take a moment to thank Jeff Golenski. Jeff is an extremely talented web and user-experience designer who graciously volunteered his time to design this sample site for us. Let’s raise our glasses to Jeff and thank him for his time and talent. Wait, you’re not drinking? That’s all right, I’ll wait for you to pour yourself something, I’m not going anywhere...

A Note About Jeff Golenski

As a freelance designer and developer, Jeff has worked with numerous organizations in southeastern New England (Figure 5.1). As the senior designer at Slocum Design Studio, Jeff oversaw and contributed to identity design, print design, and web interface design, to name just a few. He also worked as a front-end web developer at Schwadesign, Inc. Today he’s a web designer and developer at Astonish, working on creating the perfect link between design and functionality using the latest standards and techniques.

Figure 5.1. Jeff Golenski, designer of the J2 Theme. Jeff spends most of his time designing and developing WordPress themes, which makes him a perfect contributor to this book.

Steps in Theme Development

As I discussed in Chapter 1, “WordPress,” when I build a WordPress theme I usually start with site architecture, then move on to wireframing, design, front-end development, and, finally, theme conversion. Jeff Golenski and I completed the first four of these steps and in the next few chapters we’ll walk you through them. This way we can focus on the most important elements and get straight into WordPress theming.

The first step is to go to http://wbgwp.com/downloads to download the necessary page templates. When you arrive at the site, you’ll notice that the design in place is actually the one we’re building. This is a good opportunity for you to navigate the site and get an idea of how the theme will function when we’re done building it.

On the download page are the basic theme files we used in Chapter 4, “WordPress Theming Basics,” the J2 Design FED and the J2 Theme. For now you want to download the J2 Design FED files (FED stands for Front-End Development). If you’re interested, you can download the J2 Theme as well. This is the finished theme and you’re welcome to reverse engineer it if you prefer to work that way.

The next steps will be as follows:

1. Install WordPress and fill the site with content (if you haven’t already)

2. Review the J2 Design files to better understand the theme makeup and functionality

3. Understand the folder structure and call template files accordingly

4. Replace static content with WordPress calls

5. Create page templates and post formats

6. Test and deploy the theme

Design FED Files

In Chapter 3, “WordPress Template Hierarchy,” we went over the files and template hierarchy required to create a functioning WordPress theme. When you download the J2 Design files, you’ll see all the template pages necessary to make this theme work. They’re labeled correctly and ready to go. If you want to, go ahead and activate the theme.

Just because we can activate the theme doesn’t mean our work is done, however. All it means is that the template pages are properly formatted, the CSS coding is set up correctly, and there are no errors in the code. Activating this theme will work, but it will display only static content because we haven’t put in any dynamic WordPress calls.

Header, Footer, and Sidebar

Single.php, page.php, and all the other page template files require the header.php and footer.php files to work. At the beginning and end of each of these template files we’ll write:

<?php get_header(); ?>

and

<?php get_footer(); ?>

These are PHP functions defined by WordPress to locate the header.php and footer.php files in your theme. Once located, the code in those files will replace the functions.

The idea here is that most sites use very similar—if not the same—headers and footers, so why duplicate them? Your goal throughout any website build should be to limit duplicate content and code when possible. If we’re using the same header on every page of our theme but don’t extract it from the template pages, then a single edit to the header just got duplicated many times. This will make managing edits nearly impossible and add a lot of work to the process of maintaining a site.

In the J2 Design files, the static content in the page template files is missing the header and footer. I’ve simply placed this HTML content in the respective header and footer PHP files. In the following chapters, we’ll convert these documents into actual WordPress themes. The first step will be to pull the header and footer into these page templates. Once we do that we’ll have a working website on the front end, but again with only static content.

The same goes for the sidebar.php, which houses the sidebar or, in this case, the <aside> content. Instead of having that content exist in multiple PHP files across the theme, we can pull that content out and keep it separate for easy future maintenance.

Theme Template Files

It’s important to have a full understanding of the project at hand. Next we’ll take an in-depth look at the design of the theme and our approach to building it. I encourage you to review the source code of the FED files and read through the developer comments. I’ve gone through and clearly defined the structure of the site and how all the static content will be replaced by dynamic WordPress calls.

Home Page

At first glance you’ll see a nicely designed website with a clean layout and simple functionality (Figure 5.2). When you take a deeper look at the design, you can start to map out the different sections of the site. The header comprises two navigations, a logo, two advertisements, and a search and social bar (top-right corner).

Figure 5.2. Home page.

The first nav menu (top-left corner) is designed to house the primary navigation. As you probably guessed, these links are made up of an unordered list (<ul>) of nav items. We’ll replace this entire list with a WordPress call for a menu. Menus, which we’ll discuss in greater detail in Chapter 7, “Menus and Navigation,” make it extremely easy for user admins to update, rearrange, and manage a site’s navigation.

The second nav menu (light blue bar) is intended to contain the site’s main blog categories. Of course, it’s always up to the user admin to fill the site with content, but it’s our job to try to compensate for the most common uses of our themes. This navigation will also be replaced with a call to a WordPress-powered menu.

Throughout WordPress we’re going to add theme support, in other words, turn on functionality. We did it with menus already. The next step will be turning on a custom header and background. By adding theme support for these sections of the admin, we make it easy for the user admin to upload an image or graphic associated with these corresponding locations or elements. The header image can be used in many different ways. In this case, we’ll use it to enable the user admin to upload the logo. We’ll set size limits and auto-cropping rules to make sure it fits in the header. If the user admin hasn’t uploaded a logo, we’ll default to the Site Title.

The two advertisements will be made up of sidebars. Unfortunately, at this moment, sidebars aren’t exactly semantic terms; they’re basically widgetized areas where we can drop widgets into place. We can prepopulate these areas with default widgets, then give user admins the ability to replace them as they see fit. The search form is surprisingly easy to implement and actually exists as a default widget.

The search and social bar should be generated by the existence of custom settings in the WordPress Admin. We can define our own settings and allow the user admin to save custom values, but this is a pretty complex task and beyond the scope of this book. For now, we’ll hard code these elements in, but I’ll also give you resources to do it right later on.

The left column is for main or featured content, while the right column is the sidebar or <aside>. The main content area starts with an image slider, then moves on to “Recent News.” The right column has a newsletter signup, social nav bar, and a series of widgets for advertisements, recent posts, and more.

The image slider is made up of an image, a title, and a corresponding link. If we were covering advanced development topics, I’d make the slider a custom post type. WordPress can store and display several types of content. By default, we have posts, pages, attachments, revisions, and menus (nav). We can also define custom versions of content and decide exactly what functions that post type will support. For example, for the slider, we could have a slider post type and the word slider would appear in the left-hand nav near posts. We could also define that the slider post type will support only a title, a featured image, and a new field for a link. This will eliminate confusion for the user admin and make it easy for him to create new sliding elements on the home page.

Unfortunately, custom post types aren’t simply defined in WordPress and require a great deal of custom code. I hope to cover this in greater detail in a possible follow-up book. For now, the slider’s content will be generated by the existence of posts in a specific category. Later we’ll also hide this category from showing in RSS feeds, search results, and other areas of the site.

The words “Recent News” are generated from the default category’s title or name. The next four posts are the most recent posts from the same default category. If the user admin wants all the categories to be represented in this area, he can have the default category act as a parent to all subsequent categories. The images located here and in the slider above, as well as the thumbnails in the sidebar, will all be powered by the post’s featured image. When a user admin uploads an image and sets it to be the Featured Image or Post Thumbnail, the image is automatically resized and cropped to any number of preset settings that we define. Later we can call the different sizes of featured images to display in the corresponding locations or even grab different-sized featured images based on whether the user is on a mobile device.

The pagination below the posts will be defined by WordPress or possibly a plugin that provides additional functionality. We’ll plan for any form of pagination, including simple Next and Previous buttons, numbers, or a mix of both.

The right-hand sidebar will be powered by a sidebar. The featured widget area (in red, at the top of the sidebar) can be accomplished in several ways. For now, we’ll simply hard code it in.

The next area of content is the footer. Current web trends showcase a lot of content in multilevel footers, and that is what we see here. The first section of the footer (with the light blue background) is defined by another sidebar. We can continue to place widgets where we like in the sections. If no widgets exist, then the light blue section of the footer simply disappears.

As discussed earlier, the social bar and now the business and copyright information should be defined by custom settings in the WordPress admin. In this case, we’ll again house this information in sidebars and provide documentation to the user admin on how to best input this content into widgets.

Post

The Post template page defines the layout and structure of a single post (Figure 5.3). You can see immediately that the layout of this page is nearly identical to the home page with a few simple changes. While the slider is gone, there’s still a large photo at the top. This photo is defined by the featured image in the post and, if it’s set, then the image simply won’t show and the content below it will shift upward. Next is the title of the post. Below the title is some metadata showcasing the date and number of comments.

Figure 5.3. Single page.

Following the metadata is the content of the post. This area comprises everything that exists in the content editor. The editor lets you define how content will be laid out, which is why there are images floating alongside content.

Next we have the categories and tags that make up the post’s taxonomy. We’ll simply request a list of categories and tags that this post is assigned to. Below the categories is the comments section.

Comments can sometimes be complicated. We can call the default comments template or go as far as customizing every detail of the comments area. Typically, you’ll want to plan for a comment, reply comments or threads, and the actual comments form. There are several conditionals that go into the comments section, such as checking for threaded responses, determining whether users are currently logged in, and more.

Page and Full-Width Page

The Page template page looks surprisingly similar to single.php (Figure 5.4). In this case, there are actually only a few subtle differences. This reminds me of the game you’d find in Highlights, the kids’ magazine, where you have to spot the differences between two images. I honestly considered having the next few paragraphs hidden at the end of the book with a “Look for answers on page...” note.

Figure 5.4. Page template page.

If you were any good at that game, you’ve already noticed the differences:

• A different-sized featured image

• Breadcrumb navigation

• A different page title design

• A tagline below the title

• No metadata showing the date or number of comments

• No taxonomy, pagination, or comments sections

Other than the differences listed above, we could simply rely on the single.php page template. If I didn’t provide you with the page.php HTML document, I’d suggest duplicating single.php and making the changes outlined above by adding new classes, removing calls, and so on.

Instead, we can quickly go through the differences at a code level and create a proper page template page. Later we’ll duplicate it to create a full-width page template. Page templates let us choose from layouts when creating pages. The only difference between the default page template and the full-width version is the removal of the sidebar with the extension of the main content toward the right (Figure 5.5).

Figure 5.5. Full-width page template page.

Archives and Search Pages

The Archives and Search Results template pages are nearly identical to the home page (Figure 5.6). In fact, we’re only removing the slider and replacing it with a page title. The title will be very dynamic, with a few conditional statements to detect what page the user is actually on. For example, if the visitor is looking at a category called “Articles,” the title would read “You are viewing the ‘Articles’ Archives.” If, however, the visitor is on a date archive page for the month of December, it would read “You are viewing Posts from December 2011.”

Figure 5.6. Archives template page.

Upon searching the site, the Search Results page displays the results in the same fashion as the Archives page. The title grabs the search query and displays it like this: “Search Results for ‘css3 tutorials.’” The only other differences from the Search Results page is the removal of the featured images and the addition of an excerpt. This way the visitor can scan the search results and find what he’s looking for with ease.

What’s Next

Now that you have a clear understanding of the content areas and how we’ll develop them, we can get started. One quick note on page templates before we do: Our templates have an excellent layout and clearly defined content structure, but there’s not much variation between the pages. You can understand why this theme would make a great learning guide. However, in the future you should feel free to change the layout however you want. You can do anything from switching up the location of the sidebar to creating a completely new layout for the theme.

Page templates add powerful functionality to your theme and give you a great deal of control over how your site is laid out. As we learned in Chapter 3, “WordPress Template Hierarchy,” you can even create specific templates for specific categories or other pages of content. I encourage you to take another look at the page template hierarchy in Chapter 3. Another glance may help you better understand the concepts after reading this chapter.