In my last post, Kel from BadCat design brought up a very important question about theme frameworks that needs to be discussed:
On the same path… If you have a child theme (I’ll use Ian Stewart’s pro/paid Thematic child theme called Power Blog, as the example) and want to customize that – what do you do? Currently we’re talking about customizing themes by using Child Themes. If I wanted to make mods to Power Blog, I’d have to change the child theme directly, thus negating some of the reasons for using a Child theme – like upgradability.
Do we get to a day where we need grandchildren themes? I think your code might be the start of a way to “group” the family theme files together. -Kel
The day WordPress starts talking about “grandchild” themes is the same day I’ll convert all my blogs over to movable type Habari.
Way back when I started talking about theme frameworks, I talked about how WP Framework stands out:
One of the main design goals I wanted to achieve with WP Framework that differentiates it from other frameworks is the fact that it’s not styled.
A WordPress theme framework should be design-agnostic. That’s why it’s a framework. It should only contain the building blocks and the most essential code (by the way, WP Framework 0.2.4 has just be released!).
Carrington gets it. Alex King built a base framework of carrington, basically extracted all the template logic and things that made his theme work into a “core” framework. When he builds themes off of carrington, he simply extends the core framework by building on top of it; not via a child theme.
So if users of Carrington blog wanted to customize it, they would create a child theme for it and modify it accordingly. Here’s two possible scenario’s that show the benefits of what I’m describing:
- Carrington blog gets an update that includes a new section above the sidebar (a feature dealing with the design, not the logic). Users would simply download/update Carrington blog and the new section would appear above the sidebar as expected. All of the user’s changes for Carrington is preserved and left intact via the child theme.
- But let’s say Carrington framework fixes a bug in it’s atomic template system (an issue dealing with the framework logic, not the design). There would be an update available to all themes based on carrington, and users would simply download/update carrington blog (or which ever theme based on Carrington they have) and the fix gets applied. The user’s modifications to Carrington blog are left intact via the child theme.
It’s important to think of a theme framework as the logic of the theme, not the design or the underlying xHTML.
To put this into a step by step process:
- Start with a blank WordPress theme framework
- Create your WordPress theme based off said framework
- Now to customize this WordPress theme (which is essentially the first two steps combined), create a child theme for it.
That’s how WordPress theme frameworks should work. In Kel’s case, Thematic already consist of the first two steps described above when it should only be the first one. So now that she’s using the Thematic Power Blog, she won’t be able to customize her theme using a child theme because it’s already one.
All WordPress theme frameworks are blank frameworks when you use a WordPress Child Theme. All of them. Every single one. Carrington; Hybrid; WP Framework, k2, a random choice from the Themes directory, a Woo Themes theme, whatever. Even Thematic. They’re all design agnostic. Although some are a bit more unsure than others I’m sure!
Anyway, whether or not the parent theme has a style attached to it doesn’t matter. By default, Child Themes only inherit the existing PHP+XHTML framework of their Parent Theme. Extracting the theme components into another “core” theme is unnecessary. Unless one is bothered by an unused, unlinked to stylesheet floating around in the Parent Theme directory.
Now, The Thematic Power Blog Theme is the first theme in a series of themes meant to act as a first step in building a Child Theme and not meant to act as a separate design framework . Whether or not that theme can be customized in a safe way (it could potentially be—my other Child Themes can) is another matter entirely. Making a framework for a framework? I don’t know. You’d have to sell me harder on that one.
@iandstewart Using WordPress Theme Frameworks http://tinyurl.com/cwmyzg .. this will be changed (non-destructive) for #thematic pretty soon
This comment was originally posted on Twitter
@iandstewart Using WordPress Theme Frameworks http://tinyurl.com/cwmyzg .. this will be changed (non-destructive) for #thematic pretty soon
Originally posted on Twitter
@iandstewart Using WordPress Theme Frameworks http://tinyurl.com/cwmyzg .. this will be changed (non-destructive) for #thematic pretty soon
Originally posted on Twitter
The way I see/understand it, if you call your theme a “framework” or “parent theme”, you should be laying the foundation for child themes in terms of functionality. Options panels, hooks, actions, filters, etc. They should be unstyled and only exist to add functionality options to its child themes.
Child themes should use that functionality within their own themes and add new functionality only if needed. At this point, it’s just like downloading regular themes, only these “special” themes get to use the features of its parent.
If you’re going to release a framework that has a lot of focus on design as well as functionality, then make that a child theme.
Making a framework for a framework? I don’t know. You’d have to sell me harder on that one.
Actually, I can see of several uses for that now that I think about it. But it’s about a million miles beside the point, really.
Ian, it’s actually closer than you think. Any theme you release to the public, regardless of it’s type (parent/child), is going to be customized; so why not make things easier for the users. If thematic removed all of it’s current design elements (and the additional xHTML needed for that design) from it’s code base, then you would have a base framework to work from. From there, to give it it’s current look you would add to the base framework by building on top of it not via a child theme. THEN, you would release that as a WordPress (parent) theme and users can customize it via a child theme. Everybody wins.
Every WordPress theme is either a parent theme or a child theme, but not every parent theme is a theme framework. I guess it’s important to look at a theme framework as the backbone and not the xHTML.
I think the larger question here, which wasn’t clearly stated in the post and what I believe users are worried about, is (excuse me if I’m missing the point here): What happens when the child theme is updated?
Users might worry that they need to upgrade their child themes, which isn’t something they should be worried about doing. Child themes I release are starting points for users to build something custom with. Nearly all users are customizing their child theme to some extent. The thing is — they don’t have to update their child theme if I make a couple of CSS changes in an updated version.
Justin, you’re talking about the exact case Kel mentioned about the Thematic powered blog. She wants to customize the theme, but if the Thematic powered blog ever gets updated, she’ll lose all mods made to that theme.
If, however, the thematic powered blog wasn’t dependent on thematic (since it would be bundled within as I described), she could easily customize it without any worries of having to upgrade her child theme.
RT @iandstewart RT @ptahdunbar: On using WordPress Theme Frameworks http://tinyurl.com/cwmyzg
This comment was originally posted on Twitter
RT @iandstewart RT @ptahdunbar: On using WordPress Theme Frameworks http://tinyurl.com/cwmyzg
Originally posted on Twitter
RT @iandstewart RT @ptahdunbar: On using WordPress Theme Frameworks http://tinyurl.com/cwmyzg
Originally posted on Twitter
updated On using WordPress Theme Frameworks with a carrington example http://tinyurl.com/cwmyzg
Originally posted on Twitter
updated On using WordPress Theme Frameworks with a carrington example http://tinyurl.com/cwmyzg
Originally posted on Twitter
I just glad there’s a good, solid discussion going on about this, cause I’m torn between the 2 options: to-framework or not-to-framework.
I have 2 far more general questions ….
(This is the polar opposite of @Justin Tadlock’s question) ….
1) What happens when the theme framework ISN’T updated?
If I build off a framework, and then that framework is no longer updated, am I screwed..? In 2yrs time say WordPress is at version 3.something, there’s been considerable changes, and the framework needs to be brought up-to-date, where does that leave the user. Does framework leave you too vulnerable to longevity of that framework..?
2) Does anyone know/think that WordPress themselves will incorporate a design-agnostic, base framework..?
1) What happens when any theme isn’t updated? I don’t think this applies any more to a framework than it does to a plain ol’ theme. You either keep the code current or move on to something else.
2) I hope not. I’d rather see a lightweight, standards-compliant theme that’s easy to learn from.
@cracks Those are two valid concerns, I’m glad you brought it up.
Yes it’s a concern: using a framework DOES bring in another reliance to your WordPress party. If you build your child on top of Parent X, and then Parent X bails or fails you, the child can in no way can survive on it’s own (can it..?). Nor can it slot into a different Parent without modification.
I’m certainly seeing it from a non-framework developer’s view. But I’m seeing more frameworks start up, and it’s a certainty that 1 will (eventually) close down (due to other work commitments or different project startups. NOT due to their workmanship).
I can see all the reasons for using a framework, but I can also see reasons not to.
Depending on which theme framework you use, your options will vary. In the case of WP Framework, yes your child theme can and will survive. WP Framework contains all the standard functionality a theme should have out of the box. So if you choose to develop a theme based on it, you’re already guaranteed a long lasting WordPress theme from the get-go. If a scenario comes up where development for WP Framework stopped (as an example, this won’t ever happen), then all that means is you won’t be getting any additional features or compatibility updates if WordPress updates the themes API or deprecates current functions like
get_header();etc. (very slim chance of happening). But your theme will still work as should. It might not contain the new x feature that was introduced in WordPress 3.x, but it’ll work.As far as porting your theme to another framework (or parent theme), that’s certainly possible. The conversion might not be as straight forward as you’d imagine since all frameworks are different, but it’s certainly possible.
Great article with a lot of useful links Keep the great work, hope my site one day be one of your lists.
Originally posted on WPCandy – The Best of WordPress
Great article with a lot of useful links Keep the great work, hope my site one day be one of your lists.
Originally posted on http://wpcandy.com/)“>WPCandy – The Best of WordPress
Good words.
Originally posted on http://wpcandy.com/)“>WPCandy – The Best of WordPress
we already have child themes for WordPress, will we eventually have grandchild themes? http://tinyurl.com/cwmyzg
Originally posted on Twitter
I don’t think people really understand what child themes should be used for. Well I guess you have certain perspectives and ideas that go into play.
1. I’m building a base theme for which all my other child themes are going to based off of. For a client who isn’t going to be changing the theme, because they are up to spec, or they will only change it at their own risk or you are building a theme for a client based off of a theme that someone already built and customizing it.
2. I’m using a theme and I only need to make a few changes, but I don’t want to lose them when that theme updates, whether it is on the WordPress.org repository or it is a theme that has upgrade support built-in.
3. I’m making a lot of changes to a theme or I want to make changes to a child theme that is mostly what I want, but not everything.
I really think people should be able to think outside of the box. Child themes were really meant for the first two purposes. There is no point becoming crazy with this, because then you get to the point where it takes 2 minutes for WordPress to load because you have 20 themes built off of each other.
Think! Build. The structure of child themes should be small changes, if you are replacing most or all of the files, then you don’t have a child theme, you have a parent theme and you should move the rest of the files to your theme.
That is really supposed to be the point. WTF? are you building a child theme that adds functionality or replaces most of the theme? What are you trying to achieve? I’m all about torturing myself, because that is just the way I am, but I had no idea others were into that as well. How about when I cut myself, you cut yourself at the same time?
I guess I’m not exactly sure what the scope is. I’m not that interested in the mentioned themes. I could not use Carrington themes as a good example, because the last time I looked, it didn’t really play well with the whole child theme paradigm. Hell, they might have changed it, since the last time I looked. It would certainly raise the minimum WordPress requirements.
Hell, I tried to explain to the guy that his method for checking whether the file is being accessed is flawed and nearing paranoid (Why are you protecting a file that doesn’t even execute PHP?) Hell, I would have just checked for ABSPATH constant and exited out, but I l33t developers do shit the ass-backwards way. What do I know, I’ve only been developing PHP web applications for 9 years with 5 year emphasis on professional projects (which is often why I only say I have 5 year experience, I don’t count the 4 years I was paying my dues).
Well, it appears I went off on a tangent and I apologize. The point is, is that if you do major changes, then you should just be using the theme as a base and creating a whole new theme off of it. If you are only doing minor changes and tweaks, then it should be in a child theme.