It’s been a really hard slog, but we’re proud to finally announce that all 42 of our themes now function on the exact same “framework” or WooFramework as we’ve semi-affectionately dubbed it. All of our newer themes (since Aperture’s release) has been using a beta version of the WooFramework, whilst older themes has been updated to 2.0.x to accommodate the framework (for help upgrading an older version of a theme, see this tutorial).
So what does this really mean?
- The core of our themes has now been standardized, which means updating (and fixing for future versions of WP) will be much easier than before.
- All themes now share more functionality in terms of options & widgets, which improves your overall experience using our themes.
- Our next step will be do start building more and more custom functionality into this framework, which will further enhance your usage of the themes. It should also theoretically mean that the themes will become more versatile and flexible in terms of how you will be able to use them (maybe including tumblelog-type functionality for example).
To say we’re excited would thus be an understatement of the plans we have for the WooFramework moving forward. It’s been quite a journey getting here, but the framework is stable now and the hardest part of the journey (implementing this in all of our older themes) is done. So now it’s just a case of onwards & upwards…
Before we go… We’d just like to clarify what we mean when we say “framework”, because we’re definitely not developing or releasing a theme framework as it is generally called. Instead, we’ve standardized some core functionality in our themes (/functions/*.* & functions.php) and created a proper interacting structure (e.g. /includes/*.*) for that core functionality. So no need for a child theme or other frilly bits; all you need to know is that WooFramework = awesomeness.
35 Responses to “Have Framework?”
congratulations woothemes and the Team!!
Congrats – I can only imagine what a piece of work that was.
And, since you brought it up: why not use child themes? I’ve always figured it was a good idea, and have been using them all along (except for with The Station – that screwed it up pretty good!
).
Any reason in particular to avoid them, or does this framework make for a better replacement way to avoid the “upgrade blues”?
I’m an absolute novice at understanding child themes. I’ve read a little about them and have used (tried to use) theme frameworks. I can see how it would be a lot of fun to learn, but there comes a time when you have to realize you can’t do it all. My whole reason for coming over to Woo was that I wouldn’t have to know any coding if I didn’t want to. I’m trying to learn a little to customize, but the beauty of Woo is that you can have something up and going in 20 minutes and customize if you want to, not because you have to.
I guess from my limited knowledge of child themes, Woo could just release updates via 1 style sheet? Be interesting to know more about that.
See my reply underneath about custom.css
We think the learning curve for child themes is much steeper, and reserved for those who know a thing or two about coding, so we’ve elected to steer away from child themes for the time being.
By seperating the framework from the theme specific functionality, we make it a bit easier to update the theme in the future, since users aren’t supposed to touch the framework files stored in /functions/.
In the latest version 1.07 of the framework, we’ve also added the inclusion of custom.css in all themes, which is outputted in wp_head() function. This will make it easier to seperate your custom styling from the themes styling, so if an update comes to style.css, you can simply update it because your styles are in custom.css.
We’ll write more in depth about that once we have deployed it in all our themes.
Yep, I totally hear you… custom css declarations are much easier than child themes. And, honestly, I didn’t take much time with The Station to try to get my child theme working; if I had, it probably would have been pretty self-evident.
While we’re on the subject (at least tangentially
) can I put a bid in for sandbox-style body classes? That would so totally rock.
I think you can easily add those yourself with a plugin. I know we use it in proudfolio http://www.jepson.no/u/7t1nh4.png
The function is in includes/theme-functions.php
Actually any theme can be used as a parent theme.
You can declare in your css file that this is a child theme of some other theme and them it will use all the html and functions of the parent theme and you just have to build the css.
If you declare this line on your style.css file for example:
Template: default
It will use the Kubrick theme as the parent theme.
Here is a good post about child themes: http://www.raymondselda.com/harness-the-power-of-wordpress-child-themes/
I think a good customization tutorial should be written, where we discuss both using custom.css and also how to make a child theme and customize that way.
Thanks for the useful link
There are al lot of tutorials on the themeshaper site. Before I came to Woo, I tried out the Thematic framework. I think those guys are great, but it was over my head and I realized I just didn’t have the time needed to delve into it, but if I were into that, I’d probably spend a lot of time hanging out here:
http://themeshaper.com/modify-wordpress-themes/
Filter hooks etc are a whole different ball game than the above link, were you purely use a theme as a parent theme, and then add customization in your child theme.
Fact is, that I’m not even comfortable using child themes, which means that most of our users have never even heard of the concept. So for ease-of-use we’ve thus decided to keep things simple.
And we know that every approach has pros & cons…
Congrats! Sounds like you have been working hard!
We always work hard here at WooHQ; we just make it seem like we’re not *that* busy!
This is a good news to all WooTheme members!
I love Woothemes because it’s simple Rock the web
But I didn’t see a easy way to translate your themes to my language (pt_BR). I will really appreciate if you just put some _e() and create a .po file.
Keep the great work guys.
Good news… We’ve started localizing our themes and most themes should include .po files within the next couple of weeks.
Wooohooo !
That’s what I’ve been waiting for !
You guys rock !!!
So you made a framework which isnt a framework, but a normal plain theme logically structured, and then decided to call this WOO Framework ?
If I understand you correct what youve done is to make a base theme, NOT a framework…
Smart marketing move though…
In several comments you state that child themes are hard to understand etc. Its not really, and I dont understand why you make this argument. Everyone using a Woo theme, which they make modifications to, should do that in a child theme anyways, to avoid problems if a upgrade of the theme must be done, or to try different mods…
btw: Is this the same “framework” as Prodigy, which Nathan Rice was building for Woo?
http://www.nathanrice.net/blog/join-the-public-developer-beta-for-the-prodigy-theme/
delete that please, thats for itheme
Nathan has never built anything for us that I know of
Where did you hear that?
Yes our “framework” is more a base theme with standard functions used throughout all our themes. We state that in the post as well
I was the one who originally started working on the base theme and named it WooFramework, and I didn’t think we need to name it anything else, just because it doesn’t do what other web frameworks do 
I’m going to try to write a good tutorial for Woo users on how to customize a WooTheme by using a child theme, but for the standard user, I think it will be a bit much for them to grasp.
Many of our users don’t even know how to use FTP, and use the theme editor to modify their theme. So having a custom.css is a good start for them at least.
But say you use a child theme for customizing your main layout and styling, and we update style.css and a few php statements here and there… they will still have to update their child theme, and it might also lead to something not working properly.
Just saying it’s the best way to customize a theme, but it still has it’s drawbacks compared to just editing the files directly and using custom.css.
Forstår det
I`m just a bit worried that if everybody calls anything a “theme framework” it will may to confusion and the term will loose its semantic meaning in WordPress context.
I understand that, but I think those who are smart enough to understand how a real framework functions, will easily see the difference.
Also we aren’t going to promote it or release it on it’s own as a blank starter theme.
Takk for input!
I think this whole thing with child themes, frameworks, and whatnot really just starts to complicate things. Why not KISS? I don’t get what the purpose of bloated theme frameworks is. I mean, what ever happened to making sites lightweight? (“oh hai! I’d like to buy a theme that uses 200 .php and 10 .css files to accomplish what could have been done with 5 .php files and 1 .css file. While you’re at it, can you make it impossible for me to add something simple to the theme myself without having to change 35 of those files? k thx bai.”) I’m all for standardizing some core functions (WooFramework Model) to make updates easier, and calling a “theme framework” for what it is: BLOAT
Don’t sit on the fence, tell us what you really mean
I agree with you Nikole
Magnus will *always* agree with anything KISS…
That’s not a bad thing! Haha I’m all for simplicity too! Just don’t start mentioning hooks or I’m going to cry.
This is great news.
Now if only someone could write a definitive document about how the Framework concept interacts with the manipulation of the standard WordPress functionality and output.
“How to Add A Sidebar Within the Woo Framework” is a perfect example. The question has been asked hundreds of times, and has been answered thousands of times within the scope of the normal WordPress environment.
Doing a search for this particular subject within the Woo Support Forums will yield several different proposed answers, none of which officially seem to have any real explanation as to what the code means or the interaction between the variables means — there has been custom code added on top of WordPress’ functionality.
Please don’t get me wrong — your themes keep getting better and better and better and the introduction of this framework is a major differentiating factor (and brilliant) for your company versus other premium theme templating companies.
But the frameworks you’ve established are both a help and a hindrance. The productization of the Framework removes the Themes and widgets further from a standard WordPress install, and subsequently further from Codex documentation.
Without any real in depth technical explanation/documentation around the framework, it becomes difficult for people like me (developer license holder) to easily assess what’s going on behind the scenes to inform better business rules around how I can sell your templates.
But then again, maybe this is only a concern in my little world.
Hey Tom,
I think a little tutorial that explains what the different files in our framework does, would benefit users who are trying to customize our themes. I was going to do one next week where I go through best practices for customizing a theme, so I might as well put some info about the framework in that tut.
Magnus — That’s basically what I was trying to say, except in much fewer words.
This is something that we’ll be talking about in the coming weeks, because as the WooFramework grows and the functionality thereof is increased, we’d most probably like to create a Function Reference / Codex of sorts, which will allow our users to use WooFramework functions in their modifications.
That’s a really interesting perspective … I’ve actually never found it hard to just go in there and toss what I want into the sidebar templates using the standard WP calls in the WP codex (plus PHP). It feels like I end up using WP_Query a lot, I don’t know. What I do like is that I can just copy the html classes from another part of the sidebar, and poof! it all looks kosher. I appreciate that kind of generalist approach in the css instead of attaching specific IDs to everything or whatever. Tom – drop me an email if you want to know how I’m using them as a sales tool. I think “sales tool” and the technology side of it are 2 very different things, and it’s all in how you approach the customer. I’d be happy to let you know a bit about how I’m doing it.
yah mon, a hook reference like on Justin Tadlock’s Hybrid theme would be awesome.