Building Smarter WordPress Themes: Making Layout Decisions, Not Options

In the convoluted world of WordPress themes that are built to stretch to infinity, and offer “all the options you’ll ever need”, its become easy to forget what delivering focused solutions to a client or customer’s problem entails.

Problem solving: it’s the reason we build. It’s the reason we scratch our heads and yell obscenities when we can’t get our precious code to work. The urge to solve problems is ultimately what drives us as creators to keep on creating.

Me? I like to design. I like solving people’s design problems and I try to create solutions that not only make web content look beautiful, but are also easy to interact with.

You’ve probably heard that spiel before, because it sounds like something a WordPress theme designer would say. That’s how I mainly deliver my solutions to people—through themes.

From my years of experience of building focused themes for clients, releasing premium skins for a popular theme framework (and now my own standalone theme), and running multiple sites of my own, I’ve learned a lot about what people want when building a site with WordPress.

But most importantly, I’ve learned what people don’t want. That’s why I’m creating the SmartWP series here on Kolakube. I want to share my ideas and methods of creating solutions that work for the user, instead of making the user work.

And I’m starting with something I’ve been dying to talk about in themes: layout options.

The Typical Layout Options Panel

A feature built into a lot of themes is some kind of layout chooser. It gives the user the ability to pick a one, two, three, or however many columns they want their layout to support. Some even offer sorting options (content on left, sidebar on right, or: content on the right, two sidebars on the left etc.).

Here’s one I built into a theme I never released. It pretty much sums up what the industry standard says these things should look like:

The idea is simple: choose from different graphical representations of what your site layout could look like, save your selection, and your entire site layout will change.

For themes that act as site builders (namely, frameworks), this is a great way to deliver simple, powerful customization options to the user. It requires little work, and is fairly easy to understand.

But for simpler themes that want to offer layout customization at a more basic level, I’d argue that options like these can be a huge overkill.

For example, while I was building Chronicl, I wanted to add some flexibility when it came to adding/removing sidebars. I didn’t want to offer every layout combination under the sun, I just wanted a theme that could support upto two additional sidebars to the right of the content box.

Since I couldn’t justify creating a new options panel for a layout with those basic requirements, I needed to explore other methods. Having sidebars in Chronicl are optional, so any solution I came up with had to be based around those moving parts.

The Anatomy of a WordPress Sidebar

Let’s talk about another industry standard: widgetized sidebars. Any premium theme worth its money will have this most basic of all features built into it.

The Widgets interface is best used for sidebars, as the hierarchy in both the backend and frontend are the same.

Dragging Widgets into a Widget area will create a descending hierarchy. Structurally, a Widget area in the backend perfectly mirrors what it will output on the frontend.

So when a Widget area is empty, how should that reflect on the frontend?

Most developers write code to detect when a Widget area is empty, and output a message telling user’s to go fill in the blank space by adding Widgets to the backend.

This is great, because it tells the user what to do next with that predefined space.

Even though the Widget area is empty, it still outputs something on the site, thus breaking that “mirror image” between the frontend and backend.

While adding an instructional message has its benefits, it can also be an unwanted replacement.

What if, when a Widget area is devoid of content, the entire section gets removed from the website? What if an entire site’s layout could readjust itself based on the user’s decisions to add (or remove) content from these sidebar areas?

Eliminate choices, and make decisions. Don’t make the user think about their layout, just give them places to put their content, and lead the way from there.

With these questions and thoughts running through my mind, I had my direction.

How to Build A Layout That Builds Itself

Diving into the WordPress Codex, I found the nifty is_active_sidebar() conditional.

As the Codex describes it:

This Conditional Tag checks if a given sidebar is active (in use). This is a boolean function, meaning it returns either TRUE or FALSE. Any sidebar that contains widgets will return TRUE, whereas any sidebar that does not contain any widgets will return FALSE.

You may have heard of or used this conditional before. Here’s an example of how I used it for the Chronicl sidebars (take note of this structure, we’ll be using it as reference for later):

<?php if ( is_active_sidebar( 'sidebar-1' ) || is_active_sidebar( 'sidebar-2' ) ) : ?>
	<div class="sidebars">
		<?php if ( is_active_sidebar( 'sidebar-1' ) ) : ?>
			<div class="sidebar sidebar-1">
				<?php dynamic_sidebar( 'sidebar-1' ); ?>
			</div>
		<?php endif; ?>
		<?php if ( is_active_sidebar( 'sidebar-2' ) ) : ?>
			<div class="sidebar sidebar-1">
				<?php dynamic_sidebar( 'sidebar-2' ); ?>
			</div>
		<?php endif; ?>
	</div>
<?php endif; ?>

That says:

First, check to see if EITHER sidebar one or two are active. If either of them are, load the sidebars HTML. Then, run individual checks on sidebar one and two, and output its contents. If there are no widgets, don’t load that particular sidebar.

While this functionality is a step in the right direction, it’s not yet bulletproof. Say we remove all Widgets from sidebar two. Since it’s now empty, it won’t load. That leaves us with an empty gap, as we can see in this GIF:

Obviously, this looks terrible. We need a fix, otherwise this whole idea is useless.

So far we’ve been able to figure out how to make our sidebars disappear when a Widget area is empty in the backend. But now we need to figure out how to make our layout change too.

Thinking Modularly

The main structural elements of the site were set up like so in my stylesheet:

.container { width: 1175px; /* 1075px is the actual width. I added an extra 100px to account for padding inside the container */ }

.content { width: 600px; }

.sidebars { width: 475px; }

.sidebar-1 { width: 300px; }

.sidebar-2 { width: 150px; }

Now that I understand exactly how my layout is going to change, I need to be able to change the widths of these sections as the layout changes.

Custom Body Classes

I decided that I’d break down these widths into body classes, so I could write specific CSS for specific layout combinations.

Luckily, there’s the handy body_class() filter I could use to add these classes to my body tag dynamically. Nice.

Using the is_active_sidebar() conditional, I could detect when to add/remove classes based on the state of a sidebar Widget area.

Here’s a basic version of the code I ended up with:

function kol_body_class( $classes ) {
	if ( is_active_sidebar( 'sidebar-1' ) && is_active_sidebar( 'sidebar-2' ) )
		$classes[] = 'container-wide'; // for three column layout
	elseif ( is_active_sidebar( 'sidebar-1' ) || is_active_sidebar( 'sidebar-2' ) )
		$classes[] = 'container-slim'; // for two column layout
	else
		$classes[] = 'container-small'; // for one column layout

	return $classes;
}
add_filter( 'body_class', 'kol_body_class' );

This conditional is very basic. It says:

If BOTH sidebar one AND two are active, change the body class to container-wide. If not, go check to see if EITHER sidebar one OR sidebar two is active, and apply container-slim to the body class if true. If neither of those conditions are true (i.e., both are empty), then apply container-small.

With a system in place that can detect changes to Widget areas, I can now alter my CSS to specifically target different layout combinations:

/* the width of my content never changes, so this class can remain generic */

.content { width: 600px; }

/* 3 column layout */

.container-wide .container { width: 1175px; }

.container-wide .sidebars { width: 475px; }

.container-wide .sidebar-1 { width: 300px; }

.container-wide .sidebar-2 { width: 150px; }


/* 2 column layout */

.container-slim .container { width: 1050px; }

.container-slim .sidebars { width: 350px; }

/* I don't need to overwrite single sidebar widths, since they were only applied to the three column layout above */


/* 1 column layout */

.container-small .container { width: 1000px; }

Of course, you’ll need to modify other properties like floats and spacing. But for the sake of simplicity here, I only showed you how widths change.

With these checks in place, let’s see what happens now when I remove all Widgets from sidebar two:

The more layouts you decide to support, the more complex your conditional logic can get. Chronicl also supports a one column layout, and will slim all the way down if both widget areas are empty.

When a one column layout is active, I also decided to center the content box and the header. This was another layout decision I made for the user, and it was all done with basic CSS and a few if/else statements:

No Options, No Problem

I think it’s amazing that an entire layout of a website can adjust to a simple change in Widget content.

Instead of creating a new interface for our layout options, we were able to build on top of an existing, already familiar interface in WordPress.

And the code to do it isn’t even anything special—it’s just a few native WordPress functions mixed with some modular CSS.

As theme developers, it’s so easy to want to reinvent the wheel. Sometimes, we just have to look around and find ways to utilize the tools we already have before going out and getting new ones.

Could a method like this have its drawbacks and limitations? No doubt. But, I think if we strive to create more focused themes—themes that serve a specific, defined purpose—methods like this will always have a place in the forefront of any theme developer’s toolbox.

You’ve Got To Make The Decisions

It’s easy to feel self conscious about your theme when you compare it to others. You may not support “unlimited” layouts, have design options, or other “coveted features” that most super-themes these days do.

But you know what? That’s fine. I’m a believer that the best options are the ones user’s never notice, because everything should “just work”.

If you spend more time focusing on the intricate and smaller details of your themes, the quality of your work will only go up.

While you won’t make a living marketing these kinds of things (a lesson I learned the hard way with Chronicl), or even getting much appreciation for them—you’ll have created a product that is so much easier for your customer’s to love.