I have a confession to make: for a long time I’ve been scared of Genesis.

Genesis is a resiliently popular commercial theme from StudioPress that is rather different than most conventional WordPress themes. Because of all its differences, Genesis exists as probably the “biggest little ecosystem” within the broad WordPress community. Why this is true is a big topic, but Genesis’s active and passionate community, and StudioPress’s marketing structure, are both big factors.

Because of the differences between Genesis and other (frequently _s-descended) themes, it can take some getting used to. As needs for various client projects dictated, I’ve slowly started to piece together what makes Genesis unique, and why I was previously scared of it.

So my goal here is to explain Genesis’s most important difference for developers. Hopefully other developers, aspiring developers, and maybe even some Genesis users can have a better conceptual understanding of how the theme works as a result.

A Quick Note on the “Genesis Framework”

Genesis calls itself a “framework.” They mean that it’s a theme that’s used by other themes, specifically Genesis child themes.

One of the more confusing terms in web development is “framework.” Like “template” or “page,” this is a catch-all term that’s frequently used haphazardly.

When Genesis calls itself a “framework,” the meaning is that it’s a WordPress theme that’s used by other themes—specifically Genesis Child Themes, which are sold in sizable numbers. We’ve explained child themes on the site before; the executive summary is that they inherit most everything from the parent theme and then tweak it.

This isn’t a bad use of the term “framework,” but it’s very different from the meaning of “framework” when someone talks about, for example, Symfony, Ruby on Rails, or Angular.

Where Genesis Came From

Two big historical facts are useful to understand Genesis:

Before WordPress 2.7 came out in December 2008, you couldn’t (natively) have template hierarchy files in a child theme that out-competed those in your parent theme. (Thanks to Leland for sourcing that release number, it’s corroborated here. You’ll notice the release page doesn’t even mention child themes.) It wasn’t until WordPress 3.0 came out in 2010 that you could have partial templates that automatically honored the parent/child theming world—because get_template_part() wasn’t there.

Genesis is a descendant of a system that was created, at least in part, before child themes were as rich as they are today.

I’m not certain how old Genesis’s oldest code is, and what specific ideas its development team has been considering since, but Genesis definitely got its start around the era of these events.

It was slightly after the initial releases of Genesis that WordPress themes got rich child theme support, and that support made its way into community-consensus best practices. As such, Genesis is a descendant of a system that was created, at least in part, before child themes were as rich as they are today.

What This History Means

Genesis makes heavy use of hooks to allow for most changes someone might want to make.

There’s an old programmer adage that “any problem in computer science can be solved by adding another layer of indirection.” “Indirection” means changing the way a thing behaves by putting another layer of transformational behavior between the programmer and the executed code.

Back in earlier WordPress versions, when you couldn’t easily change the way a specific page looked in a child theme by copying a template file over and making your light modifications, you had to jump through hoops to make rich child theming possible. In other words, you had to add an extra level of indirection. The tool you used to do it was WordPress hooks.

Genesis makes heavy use of hooks—primarily action hooks, as well as filter hooks—to allow for most changes someone might want to make. I think it does so as a function of its history: hooks solved a problem that child theming hadn’t yet solved. However, the indirection of hooks in themes has other benefits — plugins can easily join in the fun, for example.

So How Does Genesis Work?

Genesis is a WordPress theme, and as such it uses the template hierarchy for deciding which file in the theme’s directory should render a page. But when you crack open one of the files from its WordPress template hierarchy, you won’t find a call to get_header , then the Loop, etc., which you might expect. Instead, you’ll mostly find something like this, from (parent/framework) Genesis’s single.php file:

<?php /** * Genesis Framework. * [thorough comment block] */ genesis();

That’s interesting: just a single function call, which calls into this function:

function genesis() { get_header(); do_action( 'genesis_before_content_sidebar_wrap' ); genesis_markup( array( 'html5' => '<div %s>', 'xhtml' => '<div id="content-sidebar-wrap">', 'context' => 'content-sidebar-wrap', ) ); do_action( 'genesis_before_content' ); genesis_markup( array( 'html5' => '<main %s>', 'xhtml' => '<div id="content" class="hfeed">', 'context' => 'content', ) ); do_action( 'genesis_before_loop' ); do_action( 'genesis_loop' ); do_action( 'genesis_after_loop' ); genesis_markup( array( 'html5' => '</main>', //* end .content 'xhtml' => '</div>', //* end #content ) ); do_action( 'genesis_after_content' ); echo '</div>'; //* end .content-sidebar-wrap or #content-sidebar-wrap do_action( 'genesis_after_content_sidebar_wrap' ); get_footer(); }

This is how you modify Genesis: you create a new action or filter function, you hook it onto the appropriate place in the Genesis hook-firing event process, and your theme is changed.

This should start to give a sense of what “indirection” means: rather than doing all its stuff in the files of the template hierarchy, Genesis calls functions, which call other functions, and may also call do_action() s. Those actions are then calling functions, which may call yet more functions.

What all this indirection gets us is that we’ve got easy ways to change the way everything works. Because all pages are finally actually built by this genesis() function and its descendants, we have lots of actions to hook onto, and we can relatively easily unhook something like Genesis’s default way of doing The Loop and attach our own.

This is how you modify Genesis: you create a new action or filter function, you hook it onto the appropriate place in the Genesis hook-firing event process, and your theme is changed. This is not uncommon in the WordPress ecosystem as a whole, but most themes don’t actually have this much need for an understanding of the whole hook system to do things.

Get Your Head Around Genesis’s Hooks

Know Genesis’s action and filter hooks, and everything is yours to control.

As we mentioned at the outset, this isn’t a Genesis tutorial. Rather it’s an introduction to Genesis for strangers. The basic thing a stranger needs to understand about Genesis is this: know Genesis’s action and filter hooks, and everything is yours to control. Fail to wrap your head around WordPress’s hook system and you’ll find yourself copying-and-pasting code and crossing your fingers a lot.

As a non-Genesis developer, I find it a bit frustrating that StudioPress’s support documents are behind a paywall. But you can quickly Google yourself onto a page like this: Genesis Visual Hook Guide. If you’ve got a handle on those hooks, and you’re comfortable with WordPress hooks in general, you’ve got all you need to change Genesis.

In the Template File, in functions.php , elsewhere?

When you’re hooking into the genesis() function, you might ask: where do I put the functions that I’m hooking on?

When you’re hooking into the genesis() function’s wealth of actions to add or remove some content, you might ask: where do I put the functions that I’m hooking on? I’m no Genesis expert, but I do it like this:

Am I trying to change one template hierarchy file? Say I opened single.php and wanted to add something to it. Then I’d add my function and hooking call to add_filter or add_action to that file of the child theme before the genesis() .

Say I opened and wanted to add something to it. Then I’d add my function and hooking call to or to that file of the child theme before the . Am I trying to change all page requests? I’ll put it in functions.php . If that gets too big, I may start breaking off and include() ing individual clearly-named files from that.

Both ways can work in either case. I prefer the lack of (further) indirection of putting my function in single.php and the ability to skip my is_single() guard clause in the hooking function. Either way, you’ll be doing a lot of hooking as you work with Genesis.

Genesis: Friend or Foe?

Personally, I have mixed feelings about Genesis.

Every event-driven system in the world has this same slightly disorienting and confusing quality when I go into it new.

I think it’s an amazing community where many many great people are making a living and getting things done with WordPress. Perhaps most awesomely, a huge number of female professional WordPress developers are using Genesis. Maybe it’s just my small sample size, but the frequency with which “Genesis” comes up when I look to the amazing women in the WordPress community is quite impressive.

But I find it disorienting to work on a Genesis site. Perhaps it’s just a lack of experience, but I find I have to think more and work harder to understand what’s going on or required to make a relatively simple change I (or a client) would like. This isn’t strictly a problem with Genesis; every event-driven system in the world has this same slightly disorienting and confusing quality when I go into it new.

I’m glad Genesis exists in the WordPress community. I’m glad that it empowers people to find a clear and comfortable path into WordPress. Really, the mini-ecosystem of Genesis I glimpse is a fantastic place. But all the indirection it contains adds (to my mind unnecessary) complexity. That makes me not reach for it when I’m building things. But I completely appreciate that the rich, supportive ecosystem it is, and why people do use it.