In the first part of this series, I outlined how theme frameworks work and the different types of theme frameworks there are.

Before you can start building your own framework, you'll need to consider how it needs to work and what it will be used for, so that you can use the most appropriate development approach from the outset.

In this tutorial, I'll take you through the factors you need to consider, including whether your framework will be public or private, whether it will be used by non-coders or developers, and what additional features you want to include.

There are two parts to deciding on your approach: identifying how your framework will be used, and based on that, identifying what you need to include in it.

How Will Your Theme Framework Be Used?

The way your theme framework is to be used will influence what you include in it and how you structure it. 

Consider the following:

• Is your theme framework is just for you or for other developers?
• Is your framework will be used by developers or users with no or little coding experience?
• Will your theme framework will be public or private?

Just for You or for Others?

If your framework is just for your personal use, then you will only need to think about your own needs when you're developing it; however, it makes sense to future-proof it and make it as robust as possible, so you should:

• use the WordPress Coding Standards
• adopt the DRY (do not repeat yourself) principle
• use code which you can validate using the W3C's validation checker. You should also ensure your code is accessible
• include comments - even if someone else won't be looking at your code, you'd be surprised how easy it is to forget what a piece of code does when you come to edit it many months later
• use version control for updates to your framework

If your framework will be used by other developers, maybe your colleagues, you will need to adopt all of the above practices, and you may also need to:

• provide documentation with an outline of your framework's structure, functions and hooks
• consider how you will share and collaborate on code - using a collaboration system such as GitHub will make this much easier
• document your versions or link them to milestones and/or releases on GitHub.

For Developers or Users?

Some theme frameworks are aimed at non-coding users who can customise the framework extensively without writing any code, while others are aimed at developers, providing hooks and functions they can use to customise and extend the framework. Others are suitable for both, with a comprehensive user interface and an API.

Just because your framework will be used by non-developers doesn't necessarily mean you'll be releasing it to the public - you might have designer colleagues who you want to give access to it, or you might let clients use it for customizations to their site.

If your framework is for non-coding users, you'll need to include:

• one or more theme options screens from which your users can make their customisations
• access to the theme customizer which you may choose to use in place of theme option screens, giving users the advantage of being able to see their changes while they make them, or you may want to choose to use both
• widget areas that will allow users to add their own content in a variety of places on the page
• menus so that users may navigate the site (you may want to include more than one area for menus)
• child themes support so that users can install to quickly create a working site
• libraries for any features you want to include such as sliders or light boxes
• documentation and support so that users know how to use your work (some of this is useful but beware of letting it take over your time)

If your target audience is developers who'll be using your framework along with their own child themes and/or plugins, you might need to consider some of the above, but you'll also need to include features from the following list:

• action hooks enabling developers to insert their own code into your template files without creating a duplicate template file
• filter hooks allowing developers to alter what's output by your template files
• custom functions which developers can make use of in their child themes
• template parts and include files to reduce code duplication. This is something you'll benefit from yourself as you work with the framework, and which other developers will find useful if theory need to create template files in their child themes. Make sure your files are logically named and structured, and add comments to the files from which they're called so people can easily find them.

Public or Private?

If you are planning on releasing your framework to the public, then there will be a whole set of additional considerations:

• if you'll be submitting your framework as a theme via the WordPress theme repository, you'll need to adhere to the theme review guidelines
• as users will be making use of your framework for any number of scenarios and site types, you'll need to test that your framework works as it should in a wide variety of contexts, and maybe enlist the help of other users and developers to help you test it
• some form of documentation is essential, either for developers or users depending on your target audience

You'll also need to consider how you'll market your framework: even if it's free, you want people to use it, so you'll need to publicise it via a website, social media, SEO, third-party theme shops, word of mouth, local meetups, WordCamps and/or other methods.

What Should Your Theme Framework Include?

A large portion of your theme's features will be determined by the needs of the users you've just identified. Having decided who your theme framework is aimed at, and if possible asked them what they'll need from it, write up a list of the features your theme will include. 

This list will include (but need not be limited to) a selection of the following:

• template files (including template parts and include files)
• functions
• action hooks and filter hooks
• widget areas
• menus
• options and settings screens
• theme customizer support
• documentation
• child themes

For these, identify:

• what the feature is
• what it will do
• where its code will appear

As well as features determined by the needs of different user groups, you might also want to include other features such as:

• Will your framework have a built-in layout, will the layout be configurable or will it be coded via child themes?
• How much of this will you include in your parent theme? Some frameworks have extremely minimal styling, while others (such as my own) are built using Object Oriented CSS (OOCSS) to make styling easier in child themes.
• Will your framework be responsive or will this be coded via child themes? If your parent theme is responsive, you'll need to ensure this isn't overwritten by any layout styling in your child themes, which is one area where OOCSS comes in handy.
• Will you add SEO features to your framework over and above what's provided by WordPress, or will users add this via a standalone plugin?
• Will you include things such as sliders, galleries, background images and more in your framework or add them via child themes if they're required?

This list may well grow over time as your needs and those of your users evolve. Make sure your framework is easy to extend from the beginning and you'll be able to add new features whenever you need to.

Summary

Developing your own theme framework is a major undertaking. It's something which will save you many hours of development time in the long run but which takes a substantial amount of work to get right. 

By taking the time to identify who will be using your framework and what features they will need, you'll make it more useful for yourself and other users and you'll make it easier to extend and adapt the framework in the future.