It can be confusing when you first start out building WordPress themes. WordPress’ flexibility gives you the ability to extend it how you want; sometimes though it’s hard to know which is the best method and to justify the route you have taken. This is true too with themes. Is it best to use a starter theme for project X? Should I use a child theme for project Y?
There are no hard and fast rules to which approach you should take but hopefully I can give you a little bit more information on where I think each type of theme has its place.
A starter theme such as _s (underscores) has a “1000 hours” of development under it’s belt to get you started on your project. It’s full of best practices and a lot of time has been spent ensuring it meets all of the WordPress theme standards. The markup is exemplary and it also has considerations for items that are usually an afterthought, such as accessibility.
A scenario where I can see clear benefits to using a starter theme is if you’re producing a theme to be sold on a theme market, or on WordPress.com. Having a solid codebase to start with means the acceptance process is going to be a quick one. Themes often require a certain level of standards and a wide to full coverage of the theme hierarchy and a good starter theme usually fills both of these criteria.
Another scenario is if you’re planning on producing a blog or magazine site. These types of sites often utilise most of the theme hierarchy as post archives are usually viewed by different routes such as: by date, author, category or tag. If you’re new to WordPress theming then this can also educate you in the different amount of templates available to you.
The “1000 hours’, however, is a bit of a false economy. If you’re building a site that only requires the use of 3 or 4 templates then you might end up getting discarding lots of templates. If that’s the case then a starter theme might add additional bloat to your project, something you should always be trying to avoid. If you find yourself only use a part of the theme then you might as well take the time to do it yourself, maybe using the starter theme as a reference.
If you have bought a theme from a theme shop then the chances are you will want to edit the theme in order for it to meet your project needs. If the theme author has then provided an update to that theme after you’ve made those changes how are you going to easily integrate their changes back into your theme?
The solution to this is child themes. They inherit all of the code from the parent theme but give you an empty sandbox in which to make as many edits or overwrites as you choose. So, for example, if there was a problem with the layout of the main menu in Safari on your parent theme and the author fixes this, all you have to do is overwrite the files in the parent theme and everything should be fixed, with all your amendments intact.
Another example of the use of child themes are theme frameworks such as Genesis.
Not only does the theme give you a starting point from a front-end point of view, it also gives you extra functionality to use within your project. This includes things such as extra widgets or enhanced comment functionality. WordPress itself does not try to solve all the problems associated with creating themes and this is where frameworks such as Genesis have sprung from. Whereas it does give users even more options and greater flexibility my personal opinion is that it is yet another dependency you have to rely on. You’re already relying on WordPress and this adds another layer on top of it. If you want to really understand WordPress then using a theme framework isn’t going to help you achieve that.
The main case for using parent/child themes that I have used is within a network of sites. Whether you’re using multisite or not, if you have multiple sites using the same core theme but with a few key differences (outside of what is possible with theme options) from site to site then a parent/child theme relationship gives you all the flexibility you need but also enables you to make cross-site changes and fixes very easily.
The biggest problem I have with child themes is that it encourages you to make implicit changes. If you need to change the position of a menu then chances are you’re changing it through a filter, not changing it in a template file. Although this is true throughout WordPress – in the front end I don’t like it. I like it when what you see is what you get and it makes maintenance a lot easier – especially when bringing in less experienced users onto a project.
The last option is where you do it yourself, from scratch. This gives you full control over everything, but the disadvantage is that it’s up to you to make sure you’ve ticked all the boxes.
If you’re starting out creating your own themes then use other themes as references. Your first theme isn’t going to be perfect but I’m a big fan of the learning through doing approach and the more sites you create the better you’ll get.
During this time you’ll come across some challenges. The beauty of theming is that these challenges come in all shapes and forms: HTML, CSS, JS, PHP and the interaction with WordPress. You’ll also learn some of WordPress’ quirks along the way which is useful when you’re working on any element of WordPress.
Once you’ve done this process enough times you’ll notice you’re repeating some of the tasks over and over. This might be a good chance to create a starter theme for yourself – one that you know is tried and tested and you have full knowledge over the decisions made to do things the way they have been done.
I think if you were given the choice when building something you always should want to know the why and the how, as well as the what. That’s what helps you become better at what you do and your work will reflect that.