Child themes have been gaining popularity recently but there still seems to be a great amount of confusion involved and I wonder whether they are the best option, despite their popularity.
In the beginning the big thing about child themes was the ability to create a child theme so that you could modify it and yet still benefit from updates to the main theme. That quickly moved on using child themes as the presentation layer of a framework, to offer a theme based on that framework to other users without needing to get into the actual framework code which would likely be updated.
Now it looks like themes are being released with bundled child themes so as to offer extra graphics. I don’t think I have seen a theme with bundled child themes where there is different functionality involved, but I may just have missed them.
Unfortunately some of these instances result in the need for ‘grandchild’ themes, and that is not a relationship you want to investigate.
Aside from the first option, the uses all seem to have something in common which is separation of logic and presentation and I can’t help thinking that if you want to bundle a whole load of extra functionality without explicitly attaching the means to display it then plugins would be ideally suited.
This isn’t a new thought, to be honest I have been harping on about using plugins to moduarlise themes for a long time now to no effect, but the more complex the underlying theme becomes the more I am convinced that a plugin or indeed several, might be a better option.
I can quite easily find reasons not to do it: firstly you are asking the user to turn on more than one thing which some believe is undesirable. Personally, I find the option to turn bits off to be very beneficial but of course you have to minded to build in that level of control.
Secondly, by making it into a plugin you open the gates for others to just use what you have produced in their own themes. Of course they can do this already, but plugins are designed to be reusable, that is point, whereas masses of code in functions.php (or however many other files) is certainly harder to work with.
Finally, if it ain’t broke…
Despite these things though I think there are some significant advantages to using plugins and keeping functions.php as light as possible. I’ll leave you to think about what those might be.
(__)
`
Justin Tadlock
I’ll have to disagree with this a bit about themes not having functions. This is actually how I build almost all of my plugins. I build the functionality into the theme first. Then, I separate that code into a plugin afterward. This way, if a user ever decides to not use my theme, they can simply download the plugin that offers the functionality they’re missing.
If things were done this way, it becomes kind of a win-win for end users. Personally, I just like having all of my stuff packaged within the theme, so that’s how I code it. At the same time, I realize that users might want to change themes, and I don’t want to force them into anything.
(__)
`
Dan Cameron
I’m not sure why you feel locked into thesis. Any custom WP developer should still be able to pull over the option values to a new theme.
I do get the point in regards to everyday users but not when custom WP is involved.
(__)
`
Alec
I have to agree with Cristi, functions belong in plugins and not themes.
We have Thesis now and don’t like at all how our client has to keep using Thesis and lose content.
We are taking open source and freedom and putting it in a prison. And paying for it.
It’s the emperor’s new clothes and real human stupidity.
Well written plugins and clean basic themes please!
(__)
`
andrew
The problem with using plugins is that you would probably want to tie them more closely to the theme meaning they wouldn’t simply slot in to other themes. That would cause the same portability issues as any theme.
I suspect that if someone developed a system of plugins that attached to a theme they wouldn’t want every theme author running off with their plugins for their own themes.
As for Thesis, I don’t really know much about it.
(__)
`
Cristi
Child themes are useful. I’ve built a hand full of child themes for clients based on Thematic just by editing css and in some cases adding small pieces of code in the function.php. It’s fast and easy work if you ask me.
However I do have to agree about the extra functionality in themes. I personally hate it!
If you use the seo features of a theme instead of a plugin (for meta tags, etc) what will it happen with all the information once you change the theme? It will just vanish. Themes should be used for presentation purposes only! Anything that adds extra functionality in terms of extra content should never be used.
For example take the “Easy Peasy Images” code for themes developed by Andrew himself. It’s great. It uses the built in WP gallery so even if you change the theme that uses it, that information isn’t lost, it’s still there in each of the post gallery and you can use it in your future theme if you want to.
This is why I think Thesis is crap. If you use it at it’s full and then decide to change it… well… you’re just going to lose some of your content… But hey! Thesis is future proof isn’t it?
I guess what I really wanted to say is that themes should be use just for presentational purposes and should not add extra content functionality unless that content can be reused by other themes or plugins!
(__)
`
gite guru
yeah I’ve got the customising the header.php file all cracked. thing is, I’m no genius with php, I’m literally just cracking css and some really basic php stuff so I’ve got a feeling that the functions.php stuff might be a bit out of my league for now (which is why themes like thematic appeal, nice & easy to customise!).
@ian, I’ll check out the forums and see what I can learn. thanks for the pointer.
(__)
`
Dan Cameron
Oh wait, sounds like you didn’t want to know the how. Sorry.
Anyways, thematic does allow it, you just have to be creative :)
(__)
`
Dan Cameron
You could do this by using CSS variables and php or using some JQuery within your header.php file. There’s a ton of tuts out there for this particular feature.
If you’re using a framework just hook the same code you’d use in the header into a custom function.
(__)
`
andrew
I think, Ian might have to confirm this, that you can override the functions.php from a child theme to add more to it.
It is certainly possible to do anything in functions.php that you can do from a theme file as long as the theme file has some hooks, filters, or widget holes for the place you want to use.
(__)
`
Ian Stewart
Yep. Check out the ThemeShaper Forums.
(__)
`
gite guru
really!? then it’s my beyond poor coding knowledge! are you saying you can randomise a header image just using the css or functions.php file?
(__)
`
Dan Cameron
I’ve been meaning to write about my opinion about child themes for a while now (on my blog): basically, I think they’re over rated and unnecessary for almost all instances that I can think of.
I do agree with you about plugins, it’s a unique idea and I never really thought about building modules out of plugins. Instead I tend to bring in custom functions that are organized within a functions directory (that I individually call from the main functions.php file). @Dane: It’s almost as if I have a plugins directory within my theme and I activate those modules/functions/features within the functions file.
Anyways, maybe the reason I don’t like the idea of child themes is I don’t see any advantage other than not having to build a theme switcher in an options panel–which I’ve already done.
Frameworks are a different story entirely, short answer: KISS. Only the large scale projects where you need one framework to manage multiple sites that each have unique layouts and options would a framework work. Otherwise, just build it as you normally would and stop worrying about hooking into template sections and trying something more complicated than it should be. For example, my “framework” for all client work is basically a stripped done version with little markup and no CSS. The functions file is my framework, where arrays handle my option pages and (as mentioned) pull in other custom functions from a manageable directory.