How Theme Frameworks Actually Work

Theme Frameworks can be extremely powerful. For non-technical WordPress users, they make it possible to create a unique site which looks like it's running a bespoke theme, and for WordPress developers they can help you apply the DRY (Don't Repeat Yourself) principle and give you the ability to build custom sites fast.

If you've been using a third party framework for a while and have become frustrated with the bloated code or lack of flexibility, or you just want to have complete control over your code, then building your own theme framework could be the best approach.

In this series, you'll learn how to create your own WordPress theme framework which you can use to build sites for yourself or your clients, or even release for other users. You'll work through the stages involved in creating the parent theme which forms the basis of your framework, adding extra functions, hooks and more. You'll also learn how to leverage these in your child themes and plugins and how to release your code to the public.

But before getting started, you need to know how theme frameworks operate and what makes them different form a standard parent theme.

I've spent time developing two theme frameworks for use on two categories of client site, developing and enhancing these over time, and I've also worked with some of the third party theme frameworks. In my experience a theme framework has a few main characteristics:

  • It consists of a parent theme designed to be used with child themes. In some cases the parent theme can also work as a stand-alone theme, but in others the parent theme only works in conjunction with child themes - the WordPress Codex defines these as 'Base/Starter Themes' and 'Code Libraries,' respectively.
  • It includes hooks and functions which can be leveraged by child themes and plugins. Your theme framework is the basis of an entire ecosystem you will be working with, and that includes the plugins that will hook into your framework.
  • If designed to be accessed by non-coding users, it will include theme options pages which enable users to customize the theme according to their needs. These can be extensive, incorporating design, layout, functions, content and more. In some cases, functionality may be provided via the Theme Customizer.
  • It may include multiple widget areas so that non-technical users can add content or code via widgets (including widgets added by plugins you write specifically for the framework).
  • It may also include script library functionality, such as a jQuery slider or lightbox. Depending on your needs and those of your users, you might incorporate these in the framework or provide plugins with the code which hook in to your framework.
  • It is extendable, with hooks allowing you to extend its functionality via child themes or plugins.

The first two of the points above are the most fundamental - without a parent theme, you don't have a theme framework. And a parent theme without those hooks and functions is just a basic parent theme, not really a framework.

So that's what theme frameworks are, but how do they work? Let's take a look at the elements of a theme framework:

  • The parent theme, and optional child themes
  • Action and filter hooks
  • Functions
  • Theme options
  • Widgets
  • Scripts
  • Extendability

The Parent and Child Themes

The main component of a theme framework is the parent theme. This may be designed in one of two ways:

  • As a starter theme, which can work on its own, maybe with customization via a theme options screen or the theme customizer. Examples of these include Atahualpa and Thematic. Both of these can be used as standalone themes without the use of child themes.
  • As a foundation to be added to by a child theme, without which the theme won't effectively power a site. Examples include Hybrid Core and Genesis. These will include the basic code you would normally find in a theme along with a range of hooks and functions which can be leveraged by child themes, and also by plugins. All this comprises an API for the framework.

As one of the key characteristics of theme frameworks is the DRY principle, your parent theme is likely to make use of template parts and include files wherever possible, meaning you can access the same code in multiple locations in your theme. This also makes it easier to override code in your child themes, as you simply create a replacement template part or include file.

I'm not going to explain the concept of parent and child themes here as that's covered in this tutorial on child themes. Many theme frameworks come with a range of child themes to support them, while with others you need to develop your own. 

If you're developing your own, I would recommend creating at least one 'starter' child theme to avoid repeating the work involved in setting one up for each project: you may decide to create multiple child themes as the basis for different types of project, for example child themes for blogs and for non-blog sites.

Action and Filter Hooks

A theme framework will include a range of hooks for child themes and plugins to hook into when adding custom code or changing the way the theme behaves:

  • Action hooks will appear at multiple places in the code, enabling you to add code to your template files via functions coded in the framework which can be overridden by child themes, or via functions which you add to your child themes or plugins. My own theme framework makes extensive use of action hooks, providing them in all of the template files to let users drop in content such as widget areas, contact details, call to action buttons and site-specific code wherever it's needed.
  • Filter hooks can be used to change how a site using a child theme or a particular plugin behaves, for example customizing loops, amending static content and more. Any static text (or code called from outside your site) should be wrapped in a filter, so that it can be altered by child themes if necessary.

It's worth taking some time to consider what hooks you want to include at an early stage, so you know what content to include via a hook and what to code into your template files directly. You'll look at this in the next part of this series.


Your framework is also likely to include a range of functions. Some of these will hook into the action and filter hooks you've already defined while others will be functions such as template tags which child themes can make use of. 

If you have any custom functions you use on a number of client sites, it's worth adding them to your framework. You don't have to activate all of your functions: you can activate a function from the parent theme using an add_action() function in your child site.

Theme Options

Theme options screens are a useful addition to any complex theme, but will be particularly useful for theme frameworks designed for non-technical users. The major theme frameworks all include multiple theme options screens in their own admin section, with options including switching features on and off, amending the layout, adding content and altering design elements such as colors, background images, fonts and header images.

You might choose to use the theme customizer for many of your options, which has the advantage of letting your users see their changes as they make them. I've taken this approach for the Edupress theme framework, which I developed for school websites with Mark Wilkinson.

Widget Areas

Whether you choose to add a range of widget areas will depend on the audience for your framework: if just you or a small team of developers will be working with the theme, you might not add any widget areas over and above the standard sidebar and footer areas.

But if your framework will be used by non-technical users, you can give them a lot more flexibility by registering multiple widget areas in various locations in your theme. As well as the normal sidebar and footer, you might also register widget areas in the header, before and/or after the content and below the footer.

The theme framework I use for my client sites includes four widget areas in the footer: the theme checks which of these are populated and adds CSS classes accordingly so that the populated widget areas will each take up the appropriate width of the page.

Your widget areas might be coded directly into your template files or you might decide (as I do) to add them via action hooks in the relevant places in your site. This means that they can be overridden in child themes, either by alternative widget areas or by custom code.


If a given script is likely to be used by a number of sites built on your framework, or if your users will be non-technical and you want to provide extra options, you might decide to include certain scripts in your framework, such as a slider or lightbox script. This can save users having to install extra plugins, but has the disadvantage of code bloat if these scripts aren't needed.

Again this will depend on your audience and its anticipated needs: if it's just you working with the framework, I'd recommend developing (or identifying) plugins with these scripts and using those when you need to.

If you do include scripts it's worth including an activation and deactivation option on your theme options screen.


If your framework is going to be useful for a range of sites now and in the future you want it to be extendable. The parent theme which forms the core of the framework is just the heart of an ecosystem which you and your theme's users will tap into to add extra options and power to their sites. This will include:

  • Child themes or starter themes - the list of these may well grow over time, especially if you're releasing your theme to the public
  • Plugins designed to work specifically with your framework, often activated via framework-specific hooks.

It may also include documentation for other developers wanting to work with your framework: most of the major theme frameworks come with extensive documentation which developers can use either to customize their sites built on the framework or to create child themes or plugins for other users of the framework to access.


Theme frameworks are a powerful tool in the WordPress developer's arsenal. As we've seen, they are vital for thousands of non-technical site owners who use them to create custom WordPress sites. But they're also a great tool for any developer who will be creating multiple sites, either for personal use or for clients. 

Theme frameworks have a number of characteristics which give them that power: they are extendable and flexible, and make it easy for you or your users to create custom sites using child themes and accessing the functions and hooks provided by your framework.

Having looked at how theme frameworks operate, in the next part of this series you'll identify what your framework needs to do and who it needs to work for, which will help you decide on the most appropriate development approach.



Related Articles