Sometimes the question you have to ask yourself is if you should fork. With a plugin, this is a fairly easy conversation. You want functionality, the original author doesn’t, you fork. But when you look at a theme, you start getting into messier territory.
In many ways, a theme is ‘simpler’ than a plugin. Theme devs, don’t shoot me! What I mean is that a plugin can be or do anything, but a theme is always a theme. While it may change how your site looks in amazing ways (and I am constantly in envy of people who can visualize like that), it really is just a theme. This is why reviewing themes is easier to monitor and manage than plugins. But that’s another conversation. The point here is that when you want to extend a theme, you make a child theme. Done.
What happens when you’re already using a child theme, though? StudioPress, a theme shop I love, makes child themes and sells those. This site is using a child theme, though it’s currently one of my own devising. Previously, it was using a child theme called Streamline, however, and it had a lot of changes.
So when do you make a child theme, and when do you extend it in other ways? It really depends on what you’re doing. While I sat and tried to figure out where my personal breakpoints were, I realized that since the best themes know they are a theme, and not a plugin, it was really easy. A great theme lets you seamlessly use a plugin to add in functionality. They may even tell you what the best ones are. Recently, Coen Jacobs wrote about how good themes never bundle plugins and he’s right. A plugin is a plugin, a theme is a theme. Keep ’em separate, keep ’em safe.
I’ve done it in three different ways for three different sites, and I’ll explain my rational below.
The Simple
One site is simple. Every ounce of functionality I needed, and more, was in the core code of StudioPress, not even a child theme was needed. All I wanted was to change some colors and add in a couple CPTs and shortcodes. That was easily done via Jetpack, which has a CSS editor, and a couple plugins. Actually, 99% was the CSS, once I sat down and looked at it. All the weird stuff was normal plugins.
Sometimes simple is a teeny bit complicated, and when that happens, I may make a custom mu-plugin or two, but in general, not so much needed unless I want a Custom Post Type. And anyway, I never put a CPT in my theme if I can help it.
The Complicated
On the other hand, one site is hella complex. I found a theme I really, really, liked. Almost. And worse, this was a child theme. It was exactly what I was afraid of. There was no way I would get what I wanted out of this theme unless I edited the functions.php file, a lot of the CSS, and a ton of the images. Could I still have done this via CSS and a couple plugins? No. Well, the CSS yes, but not the code. I had need for some crazy functions, a total re-write of comments, and the list went on.
In this case, I forked. I ripped out the small amount I never wanted. I added in the medium amount I did want. I directly edited the theme’s CSS, added in a post template, and changed all the images to my chose color. I even added in a different font. Could I have re-written from scratch? Of course, but the theme had 90% of what I already wanted to do.
There actually is a step before forking, and that would be using plugins. I know I mentioned plugins before, with the simple themes, but actually most theme frameworks are extra special. They often have custom plugins like Simple Hooks, which fundamentally lets me do everything I might do in a functions.php file for that theme. This means most of the time, I don’t fork. But. This theme really was so complex that I needed more than just the simple hooks. Genesis Complex Hooks may have done it, or another plugin to make a transient functions.php (ala CSS editing). And that would have done it except for when I wanted to change a lot of images, add in JS, and then a custom page template …
Well you see how it goes. The point here, however, is that I sat and thought about it, studied my setup, and made a long term decision. Originally I was using the plugin way, but when it stopped being extendable, I decided to do this, and I regret nothing.
The Original
The last option I had was I theme I kind of liked, but it was old. It was pre-HTML5, it didn’t have microformats, but more-over, it wasn’t aging as well as I would have liked. I made a list of what I liked about it, what I didn’t, and what I really wanted. While the list was short, it was also clearly not going to just be CSS. I wanted a custom front page, an extra page template, images, and Genericons built in. In short, I wanted this theme to be something that could carry me onward, regardless of a plugin, even one I wrote.
I have not made my own, 100% from scratch, child-theme in a long while, and this one may not really count since I was designing it to look like something else. This took me an afternoon to bang out the basics, and a couple days of minor fixes here and there to perfect them. Release and iterate, as they say. Certainly, I could have taken someone else’s theme, but it was going to be a surprising amount of work to do that. Instead, I made a list of my needed features and my desired options, and went to town. It’s still a pretty simple child-theme (which speaks well to the inherent extensibility of the parent), but now it’s mine, and it’s easy to extend it and expand it.
The Rest…
What about you? What do you think about when deciding how to handle a theme that needs changing?
Comments
8 responses to “To Fork Or Not To Fork”
Excellent discussion here. I have contemplated much over this myself. I used to fork Twenty Eleven on everything, and customize it how I like, and add plugins as needed. I did this with appx. 200 different sites with different requirements. It worked well for most sites until the theme Twenty Eleven was rewritten to be more responsive, with many security and other updates. I was not able to update the forked themes so I lost the benefit of having the WordPress Community improve the code I was using for the 200 sites. My error was in that I didn’t foresee that there would be better technology available later and plan to allow for those updates to be able to occur. If you plan ahead by using a child theme, you will always be able to take advantage of new features as they are invented! If I had to do over again, I would definitely use child themes of Twenty Eleven, and I just may do that on some of the more important sites. 🙂
I had never used a child theme or framework, and my only exposure to child themes was through developing for BuddyPress. I found them to be annoying, cumbersome to work with, and disorganized. BuddyPress has come a long way, and now special handling of the theme is not necessary. It is now recommended by many to create a child theme to make modifications to any theme you use. As a result, I took on a few projects where I was forced to use child themes where I learned a lot. I have used this knowledge for content on several sessions on how to create and work with child themes. (See my slides on Using CSS3 in WordPress and Twenty Thirteen and Modifying with Child Themes).
I think frameworks are great and they can save a lot of time for some people if it does what you need it to do out of the box without any customizations. For me personally, I don’t have much experience with them and prefer just the native features of WordPress. I trust that the right decisions will be made re: adding new features that will require hours of end users training, (i.e. Post Formats in 3.6) and that the functionality of core will maintain its commitment of being lean, mean, and extremely stable and reliable, but extensible with plugins. I have been hearing a lot about keeping functionality separate from the look of the site, which I totally agree with and the raised awareness of this is most excellent.
When I develop or look for a plugin for something, I make sure that it is using and/or playing nice with the full functionality of WordPress and all of its wonderful features. It is also a good idea to review the plugins that you are using and upgrade or remove them as necessary over time, on a set schedule, for example, every 6 months. You will find that many plugins are eventually replaced by functionality in core and that the plugins are no longer necessary. I used to have a slew of plugins to manage menus when there was 2010, then with 2011 those plugins became unnecessary and redundant with the revamp of the menus. I also usually test with Jetpack as well, as I do like that plugin for a lot of things, but it does tend to have conflicts with a lot of plugins, ie. Viper Video Quicktags, which I believe will become redundant when WordPress 3.6 arrives.
The trick to frameworks is realizing they’re just themes, Ed 🙂 Really the beauty of a theme, framework or not, is how easily can I extend it without making a child theme or fork, and have my changes be portable. A framework is just a theme with easy ways to do that (Genesis has an export option for your theme settings), and even with customizations, most of them can be done with the right plugin, which shows me they’re thinking of things the right way. That I can run 90% of my sites with only needing a CSS editor to make colors purty tells me I picked right 🙂
(I’ve never had a problem with Vipers and Jetpack, and used to use them all the time… How odd)
The problem with child themes is the trouble it takes to remove functionality and design code you don’t need when the parent theme has a fat functions.php and a bunch of LESS. Chances are it remains that one last thing to do that you never get around to doing.
If you’re removing functionality from the parent theme in your child, I would think you are, perhaps, using the wrong theme, eh?
CSS/LESS, sure, I can see that, but if I look at a parent theme and think that it’s overkill, then I should be forking and making ‘Theme Lite.’
Not necessarily. If you just want to add and remove some actions and filters, you can doing this in your child theme’s functions.php. You just have to know how to do this and go through the parent theme functions, cutting and pasting stuff until someone builds a plugin or theme framework that automates the process. It’s not something explained in the codex (or anywhere) in any kind of detail, unfortunately.
In part that’s because it depends on the theme :/
TwentyTweleve IIRC was written so some of its functions were easily overridable. It checks if the child has it and, if so, uses that. But most don’t do this.
But since there isn’t a theme ‘standard’ for function names, you have to know what one to override (let’s be fair – that’s true of ALL functions 😉 You gotta know what you don’t want, which is a PITA). A lot of themes are now making those sorts of things filterable (I know Genesis is) so you just filter the function and off you go, no remove needed. All that said, Otto wrote this in 2010: http://ottopress.com/2010/wordpress-protip-child-themes/
Still true 🙂 it’s not even really a ‘Theme’ thing so much as ‘Oh you want to replace a function?’ and holds true of a lot of WP things still.
Urg, sorry for the typos. 😡
Hopefully all ‘frameworks’ will make everything filterable, but a handy-dandy all-purpose child theme generator plugin would be nice for general use. Lists all the functions in a theme, lets you pick which ones to keep, and then it spits out the new kid.
Not all functions are filterable, and not all are in functions.php (which is where Frameworks start to win, since they usually have better documentation 😉 ) but that would be a great start!