This is where I share my ideas, inspiration & thoughts. Generally though I'm just the Creator of Rockstar Awesomeness and this tumblog is further proof of that.
Follow me on Twitter if you prefer me in more digestible chunks or if you really like me, then read more about me.
Hosting by RSAWEB
Copyright © 2009. Powered by WordPress. Remember that it’s not so rockstar to steal from others.
So I’m sure that I’m not the only one taken notice of the variety of “theme frameworks” that have been popping up in the WordPress theming community of late. Fact is, even though “frameworks” such as Thesis, Flexx & Thematic are great themes, I highly doubt their viability as a supposed “framework”. The recently published “Future of WordPress Themes 2009″ post, where most were raving about these frameworks, propeled to challenge their views on the matter.
Taken from Wikipedia, this is what I consider the concept of a “framework” to include:
A framework is a basic conceptual structure used to solve or address complex issues.
A software framework is a re-usable design for a software system (or subsystem). A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an API.
Now before I get into discussing my thoughts on the viability of these frameworks, I’d just like to qualify myself as someone with an experienced and knowledgable opinion in this regard… I think I’ve co-developed and bug-fixed enough themes (on WooThemes and Radiiate) in the past 2 years to know my way around a WordPress theme. Secondly, having dealt with an army of users requesting design & functionality modifications on our WooThemes, I believe I have a pretty good idea of what the end-user wants. So here are my thoughts…
I’m all for decreasing development time on projects and I believe that a framework (or more accurately – a project workflow) should enable that; so in this regard I’ve got a little base coding framework (not a *theme framework*) of which I base all of the WordPress themes that I develop. This is easy and efficient, because I know exactly what’s going on in my code. If for example I was using one of the abovementioned themes, I would’ve needed to teach myself the ins & outs (i.e. a sub-set of skills) of the theme, before I could do the development as quickly as I could without.
Ultimately, a theme framework will never make as much sense for anyone else as it does for the author of that framework. Take Thematic for example – nobody can tweak the theme as well as Ian Stewart himself can (take a look at the awesome iteration of Thematic on Themeshaper). Another example would be CopyBlogger which runs on Thesis; would anyone else (the laymen; not the WP rockstars) except Chris Pearson be able to pull that off? I highly doubt it…
My conclusion would be that anyone without the intimate knowledge of a framework would thus be limited (to varying degrees) in terms of their modifications of the theme. And another question I need to ask is whether it is actually viable in itself to try establish that intimate knowledge of a single framework!?
I know for a fact that Chris Pearson might strongly disagree with me here (judging by some his tweets in the past), but I’ll stick my neck out there… 
I actually believe that both Thesis and Thematic are superb themes (and I’d be able to recommend them to anyone); but that still doesn’t mean that I’d use them myself.
Consider the WPUnlimited theme that popped up in the last few days… Without testing the theme, I can honestly say that I’ve never previewed a theme’s backend features and felt that this was truly overkill. I mean seriously; do you really want drop-down boxes for font-family & font-size CSS attributes, along with Javascript colour droppers to mix+match your colours? I know I don’t… I do think that this is an extreme case of (possible) code bloat, but I have a point…
A framework per definition includes features & functions that are not necessarily going to be used, which means it does a helluva lot of different things from a bunch of different people. Great. But consider that when 75% of those features aren’t used by the end-user, that your code suddenly becomes bloated like hell. Instead of having to make quick / easy tweaks to the code base now; the user has to delete the code that they’re not using (i.e. to clean things up).
So without being a hypocrit in this regard (since WooThemes had one of the first themes ever with an options panel – for example), I just think that there’s a balance when including features that most may not use versus keeping the code as clean (and minimalistic) as possible.
This related back to both of the above… Considering that you now have a super-specific theme framework (tailored to the ideas & skills of the original author), along with a bunch of custom, non-standard WP functions – you’re pretty much stuck with getting support directly from the source, since the wider community won’t be able to help you out.
Again, there’s a balance in this and this probably comes down to personal preference… But I’d much rather enable the end-user to have a much wider knowledge base on the biggest part of the questions they may end up having (i.e. more general WordPress queries). Obviously with a specialized theme, you’ll find that there’s less general help available to the end-user.
I’m no end-user and ultimately all of the views above have just been influenced by end-users (to some extent). I just can’t see anyone create one theme that’ll rule all others. I believe in developing niche themes that are 95% suited to a specific user’s needs; so that all that is left to tweak is the options in our backend, along with any CSS / front-end modifications.
We have to consider the end-user’s capabilities here and even though I can delve through the awesome code bases of Thesis, Flexx & Thematic, there aren’t many end-users who can do that. And I also have to exclude the kind of developer that has only heard of CSS before; thus not really knowing their way around HTML, CSS or PHP (the kind that just knows enough to break and fix a theme based on trial-and-error).
So I’m open to be persuaded / proven otherwise… Who wants to try?
I believe the exact same thing. Yet we disagree on why and how a properly coded theme framework can make this happen, as in, extremely easily.
I could go on and on, but a properly coded theme framework has no code bloat (or at least very little), reduces maintenance for both developers and users, and is easier to tweak than other themes (especially for non developers).
But in the end, I think this is probably going to be one of those personal preference things. Like, is it better to develop a theme with a PSD mockup first or dive right into the markup and CSS. It’s what works best for you, right?
I can tell you from the support end that more “features” of a framework that hide, move, or alter the expected code of a WordPress theme end up confusing anyone who had any inkling of what to do with a WP theme before.
Both Flexx and Thesis are terrific themes from my own experience, but they differ in their complexities with huge contrasts in code.
Flexx offers huge wireframe configuration changes with no coding needed, but completely eliminates the possibility of a developer/designer using the theme for their business to meet a finicky customer’s requests.
Thesis almost completely hides the existence of the usual WordPress code as a developer would expect to go to the WP theme file editor and jump in and make a couple of changes, BUT opens up the world with the custom functions and css files if you know code, which you only need to do if you want to do more than the hundreds of options coded into the dashboard interface.
The theme killer will figure out the best mix of allowing changes without needing to code, accessing the code as a developer, and cutting out bloat.
Valid and good points made here. The only “framework” I know is that which we build our WooThemes on, and I’ve never tried any of the other (so-called) frameworks. I’m a coder and I know that 95% of users don’t even know their way around our code framework properly, so how are they supposed to manage a “proper” framework?
I don’t believe this will be the year of frameworks, at least not for the end user of a WP theme. It might be the year of the framework for the framework author, but then it’s all rather subjective isn’t it
We’ve had frameworks to use internally for years. Show a client one of a series of possibilities to base work upon and off you pop. A designer can then be hired if necessary, to show how it should look, but the structure and functionality is pre-defined.
But would we release these to the public? Well, for another developer or a designer they could be useful, but there’s also an awful lot of our IP in there. We’ve developed, and spent many months getting it right, code that’s very specific to media portals. No way are we giving that to the world for quite a while – they’d be able to undercut us
Whether these frameworks catch on is a different matter – but we designed a theme with a carefully structured and sliced up FireWorks png (one click and you’ve re-exported all the graphics), a paramaterised CSS file, and we watched as most people just picked up the pre-supplied styles and went with them. I personally think you’re right (as are the chaps at iThemes) in simply finding needs and fufilling them simply with straightforward themes. A good designer can tweak a good theme quickly anyway.
I love frameworks, but it helps allot as I can read and understand PHP.
I’d rather call WP frameworks, WP PHP frameworks. Because most of what makes a framework in WP a framework, is someone taking what is available and creating function/logic around the common WP features and function and then (unfortunately for the End-User due to their natural lack in programming knowledge) makes the theme somewhat more complicated using PHP.
It only makes sense to develop a framework, even if it’s a small one. It saves time and can create handy shortcuts and ultimately speed up dev time.
Oh – another thing I meant to say – have you ever tried explaining child themes and how to install them to a non-techie? Quite painful I’m afraid….
Actually, no, I don’t either but a surprising number of users *do*.
And it’s growing. They don’t want to muck around in code becasue they don’t understand it, they don’t want to, whatever.
But they DO want to lightly edit their theme and just change a few things.
I’ll stick my neck out and say I’m a little “meh” over frameworks as well. Yes, I can code and I’d rather just code something right in the theme instead of using the extra functions and frameworks. I’m not interested in future theme upgrades, as some of them are too frequent and chances are by the time I would get around to upgrading my theme, I’d feel like changing it anyway. I want as little code as possible in my own themes.
* is also well aware she’s using an old theme.
New one has been in the works for ages
Framework themes shouldn’t be used primarily by wordpress users, instead developers should take the full benefit of.
I just couldn’t make anything as complex as Thematic from scratch all by my self (and Thematic was based on Sandbox) so why build something that could prove difficult to improve and maintain when there already exists something that fits the bill.
For me it speed up dev time by a lot (mostly because I don’t have to write the html) and this way I can spend more time on design details which can turn a good site into a great one!
I can see both sides of the argument. I think it depends entirely upon who you your end users are.
In Adiis case the “framework” is a base theme that new themes are created from, the end users are customers who purchase one off themes (or subscribe) and he doesn’t want to complicate things by having to explain child themes and the update process. Some customers will modify the theme to their needs but most will just upload it and use the default settings
In Ians case (with Thematic) I would say that developers are the audience, more specifically WordPress website designers/ developers. From their point of view they want a simple easy to update base to create new designs from quickly and easily. With Thematic you can quickly alter the styles and formatting and not have to worry that future framework updates will break your layout.
Personally I am sitting somewhere in the middle, and am trying to make use of the best elements of both. I have a single folder in my theme that has the core functions and this can be updated at any time. The actual templates and css can be changed per theme.
Very interesting debate and one I’ve been pondering over, though not really doing too much about for a while. I think the debate has a different slant depending on which side of the fence ur sitting on.
My perspective as a “theme developer” and generally someone who uses wordpress to create client sites is that a framework needs to be flexible, easy to modify & easy to extend. Something which is modular would appeal to me, which allows you to plug in pieces instead of having to switch on pieces.
Code bloat is one of the main problems, especially for a non-developer or a junior level developer so I think not all frameworks will be made equal or should be made equal and the level of difficulty should depend on who the target audience is for the particular framework.
I’ve looked at a few frameworks as well as premium themes which allow for flexibility and pretty much all of them suffer from one major problem, too much heavy theme options which scare the living daylights out of anyone other than an advanced wordpress developer or the theme/framework developers themselves, so I agree with Adii regarding the framework making much more sense to the developer, though that should be obvious.
When I started working on creating the learning theme, which is still in progress, I tried to keep everything as simple and core to wordpress as possible, meaning not too much custom code. My target audience was of course newbies wanting to learn wordpress coding from scratch.
I think documentation goes a long way to keep things clear with frameworks, as well as code commenting. I also think the formatting of the code is important, and making code pieces modular bits which can be shuffled around and added or left if need be.
I think the flutter plugin system is making a great dash and establishing “framework” which can be integrated into any type of wordpress theme, which might be something more worth investigating, so for example, make your theme the way you want to and them plugin some external elements to extend it’s functionality, though of course this also requires a certain level of wordpress coding knowledge.
Ultimately, it depends on whether your target market are users, developers or user/developers and at which level they’re at.
Theme Frameworks are the new breed of WordPress themes. They’re basically WordPress themes done right. Now everyone has their own opinion in what should go into a theme framework and that’s why you have so many out there. WP Framework, however, isn’t personalized by it’s author. It doesn’t contain it’s own design or anything that personalizes it from the start. Theme frameworks, IMO, aren’t meant for that. 2009 will be the year of theme frameworks. I view your thoughts as the last generation of theme authors not accepting the newer, better way of creating WordPress themes (from scratch). You don’t have to use what’s out there. Roll your own theme framework specific to Woothemes. It’s all about efficiency. If a theme framework doesn’t speed up your work flow, then it’s not performing it’s job.
I got lost way up there in the whole child themes cocktail… All I know as a WP user is that I am only becoming familiar with WordPress admin after several months. With limited coding abilities I am a trial and error user. So I am always looking for themes that not only offer new ideas packaged nicely, but that are simply to use and have the support to back them up.
I just want to know when one of you gurus is going to make a plugin that lets a chop like me create new sidebars and assign these sidebars to categories, posts, pages or templates. Now that’s something I would pay for.
First of all, let me say that I was EXACTLY where you are, Adii, with regards to Frameworks less than 2 months ago. I thought they were bloated, complex, etc. To a large degree, I still do (as I said in my contribution to Ian’s post).
First of all, though, let’s define a framework the way theme framework developers define it.
It’s not about having a “base theme” that you can modify to make a new theme. That is NOT what devs mean when they say framework.
It’s about building an APPLICATION (in many ways) that needs NO direct modification. However, that doesn’t mean you can’t modify it … it just means you have to do your modifications in a slightly different way.
For instance, if you wanted to change the way the WordPress core files worked, you would be stupid to actually modify the core files. Thus, WordPress introduced the plugin system coupled with the use of actions and filters so that you can change the way WordPress works without actually modifying the core files.
In that same way, theme frameworks are built using the same action and filter system that WordPress uses.
But why?
Easy … just like with WordPress, if you’ve made your modifications to the way the theme runs via a child theme hooking into the actions and filters, when the theme author decides to come along and update the theme, your changes will remain intact.
Protecting user modifications has been one of our biggest headaches at iThemes, which is why we opted to build our new theme framework. From now on, all our new themes will actually be TWO themes packaged together — our iThemes framework, and the child theme that is build on that framework.
Is it bloat? Yes. Is it unnecessary code? Yes. Is it extremely complex? Yes. But we’ve concluded that the benefits (protecting user modifications) outweigh those negatives.
“Coming from someone who is building a theme framework, actions and filters are not easy concepts to grasp. will be hard to educate users.”
– Nathan Rice on Twitter
Adii, nice post… very interesting. I’ve thought out frameworks for a long time, flipping from side to side, trying to get whether its a good thing or not.
Your right about most end users not wanting to build off of some framework that they don’t get, but I don’t think frameworks are truly meant for those people. There are a lot of different niches of people out there and a group of them want to make there own theme without doing all the detailed work and this is where a theme framework comes into play. They can make a child theme, which builds off of a good base. But here is the thing, Woo Themes customers are not these people. Woo Themes is after a larger group of people who want an out of the box product, rather than a do-it-yourself project. Most framework theme users know PHP, HTML, and CSS. Like to redesign their site every 6 months, but don’t like doing every last detail. Want to call it there own, rather than a modification. And most importantly, learn though the code of more experience theme developers.
If frameworks take off, its not going to be because end users are using them knowingly, but because other themes –child themes– have them bundled and use them as a starting point.
In short, theme frameworks are a niche product, not an end all solution in my opinion.
First off – Thanks to Adii for putting yourself out there to represent what might be the “silent masses” on this particular topic. Just because “big names” in an industry believe something is right, doesn’t make it the case. I haven’t decided what my feelings are with regards to “theme frameworks” for Wordpress yet, so open and civil discussions like this are a very important part of the process for me.
I would like to point out the fact that these types of discussion are common to EVERY platform and technology. Should we expect Wordpress be any different? Whether you agree or not, I’m sure you can admit that it speaks volumes about the level of planning that has gone (and continues to go into) Wordpress that unique concepts like child themes can be implemented and enable a framework approach to design / development.
Java developers seem to be the most passionate about their ‘roll-your-own’ frameworks, but are starting to see the benefits of shared presentation architectures with robust tools like Java Server Faces (JSF) and Spring.
PHP has multiple frameworks (CodeIgniter, Symphony, CakePHP and dozens more) to help projects scale their development and support processes.
The populous have recognized that patterns like Model View Controller are a best practice for a reason. Even things as relatively new as Flex have multiple options for frameworks.
Nathan hit the concept perfectly, “Is it bloat? Yes. Is it unnecessary code? Yes. Is it extremely complex? Yes. But the benefits outweigh those negatives.” Everyone is more than welcome to roll-their-own, but much like the arguments in favour of open source versus closed source development, there are benefits to collaboration which bear out over the long-term.
If nothing else, it gives a definitive “YES” to the answer of the question about “Is Wordpress dead?” which was going through the echo chamber of late.
I can’t speak for anyone else, but the best “framework” in my opinion is a blank template. One folder containing a foundation of blank files (header.php, index.php, footer.php, etc.) and empty folders (images, scripts, css, etc.) necessary to create any WordPress theme. Yes, I have templated styles, functions and code that I reuse and modify for each theme that I make, but for the most part, I can crank out the “basic” groundwork for any theme concept I have made within about 30 minutes using my template. I guess what I am saying is that if you have a relatively solid understanding for WordPress theme development, there really is no need to use a “Theme Framework” developed by someone else simply because it will never be perfect for your specific needs.
It sounds like Nathan is on the right track by building his own “framework” for his own biz specifically catering to his own needs. Thats the way to go IMO.
I think a theme framework — that is, a theme built in order to build other themes — is most useful really when it’s used and created primarily for the developer who created it. Some others above said this already, but it’s worth repeating. So I’m most likely to shy away from other developer’s frameworks, honestly, because I’m too proud to use them. I want to use something that I develop myself, you know?
That said, it’s hard to deny the usefulness of them, especially when we’ve all seen the benefit in using a framework of some sort throughout our web development work. Having a launch point can speed things up, but can also help you benefit from past success. That’s helpful.
What I’m not crazy about, though, is using other’s frameworks. I’m not interested in using other’s frameworks for my work, I’m more interested in creating and using my own. And, honestly, I think every developer should.
Will all due respect, Adii. I was using a Woo theme and spent countless hours customizing it for a really bad*s$ looking website. But then, shortly after WP2.7 came out my site started acting funny. Posts weren’t showing up anymore. I checked out the support section at WooThemes and learned that I had to upgrade my theme files. WHAT?!?!? I don’t have the time to customize that theme again.
So, I have switched to Thematic and am creating my own child theme customization. I have to say, I am happy knowing that I can upgrade the main Thematic theme without ever having to change my child theme again.
In my opinion, the very fact that WooThemes “wants to keep things simple” by avoiding a framework created a lot of complication and work on my end when I had to upgrade.
And you lost my account and my hard-earned $$.
I’ve been speculating for some time that themes are heading towards modularity, either by bundling plugins, or by producing a theme based plugin functionality. This would be a simple enough matter in my opinion.
I wonder, if you looked at all the code in all the frameworks and began to separate it out logically into plugins how many you would have, how many combinations you would have, and how much you might turn off for any particular niche theme.
I agree with whomever it was that said that frameworks were mostly PHP. That being the case there is no reason why it must be automatically turned on with no way to turn it off.
Maybe I’m wrong in all this, but I view the whole existence of frameworks as an attempt to solve what is becoming an increasing problem for developers who create and manage lots and lots of WP sites: the lack of a real templating system. The WP-hooks are not a templating system.
If you look at Thesis, Thematic and Carrington, you’ll see that’s what they really are, templating systems. I think the term “theme framework” is a misnomer because it makes it seem like the end user or theme “buyer” should be aware of all the functions and hooks; I don’t think that’s the case. The real benefit from a templating system comes with agile development and that’s really not aimed (nor should it be) at end users.
I think you come at frameworks (or templating systems) from the perspective of someone who sells ready-made themes to end-users. Sure, developers and site designers use Woo Themes too — but I’d guess the bulk of your sales are from end users who like the addition of stylesheets (which is really all a child theme is — and before people start yelling at me and saying that child themes are “so much more” – clearly I’m oversimplifying, but thats the essence of a child theme) and the backend options to add and play with plugin stuff.
OK, for those users – no, a templating system is probably of little use — but again, that’s totally not the audience (at least not unless one templating language really takes off).
And you’re right, for someone like you who already has an agile workflow, learning a new templating system (let alone learning four or five) is not conducive if you are trying to save time. But for developers who either don’t have their own agile system in place or don’t want to spend the time creating one, learning the templating language and additional hooks is absolutely a time saving and productivity increasing measure.
Here’s my only issue with frameworks/templating systems: there are already too many of them. As a designer, I don’t necessarily have time to investigate, learn and then try to implement every single framework to see what works best. That means you either try to create your own agile system or commit to learning and using one more than the other. This puts widespread acceptance and adoption of these systems at arms length (because it is all very chicken and egg) and really limits how many child themes, add-ons and other innovations that come out of official templating systems.
Sandbox (which Thematic was derived from — though obviously it has evolved considerably now) looked like it had the best shot of making it into WP-Core; now that it’s gone (or at least, it’s main developer, Scott is no longer developing it further), Alex King and co’s Carrington probably has the best shot of being included in WP-Core. I think Thesis is a really, really great “framework” and although I haven’t talked to Chris specifically about whether or not he views it as a templating system of sorts, I’m sure he does — seeing as he has put so much of that sort of functionality into it, but it isn’t GPL (and I’m sure it won’t be), so that’s a wash.
If something like Carrington or Thematic or another framework/templating engine was integrated into WP-Core, even as an option, it could open up all kind of possibilities. That would then be what end-users who want to modify could “learn” rather than just WP-hooks.
Maybe I’ve been spending too much time with Django and XSLT, but from a development standpoint, I really enjoy keeping my code and my design elements separate from one another and that’s where frameworks become really attractive.
Coming across this post is funny because a friend and I just got into this conversation recently … about how all these “hooks” and such just make for an overcomplicated, bloated product which distracts from the beauty in simplicity that WordPress is. The guy who does Thesis promotes it like it’s the second coming and then makes it so complicated that you need a huge tutorial to get inside Pearson’s brain and figure out how it works. (We were actually shocked he didn’t come here to comment on this one.) I’ve actually enjoyed working with the WooThemes and I’m on my 6th one right now … the simplicity is key for me, being able to go in and just make WordPress calls when I need them. As for the update issue, it is true that I would never expect every theme and plugin to work with every new update of WordPress. Perhaps the answer there is for the makers of the theme to just tell you which lines were changed to fix it in the dev notes instead of requiring you to reinstall the whole updated theme. As your theme “end user” … I’m a php developer. I know how to use WordPress. I just want to save my clients some money by giving them the option to use a template design rather than paying a designer to come in for custom work. It works down to the most base level too, though … even the newest beginner can at least figure it out through the documentation and the WordPress codex. If you can install WordPress itself, you can figure out how to install a WooTheme. If you have a bunch of time on your hands to waste before you give up and call a developer, I guess go ahead and stare at the Thesis documentation for a few days. (I think most beginners would give up after just reading that, well before they even tried it.) I know he has his own fan club and whatnot, but I don’t want a cult or a “framework” … I want a nice/pretty design that works with validating code and css.
I think most beginners would give up after just reading that, well before they even tried it.Thanking you
I see I need to add blockquote styling to my comments kind sir…
I agree that this issue will very much be influenced by personal preference and personally I have always had the preference of building custom, client WP themes from scratch instead of using any framework specifically.
In terms of what you’re saying – do you feel that Thematic is “there yet” in terms of code bloating, reduced maintenance and ease-of-use?
We actually built Carousel.no off of Thematic (to test it out) and even though the code base was lovely, Foxinni ended up deleting a bunch of the “unnecessary” code. So this isn’t necessarily a bad thing, but it is a reason why I’d never fully adopt a framework.
Great article Adii, and great comment by Ian too – for the most part my feeling on frameworks is that they try to do too much, which inevitably means that they try to cater for everyone and end up being “just right” for no one. Just my 2c.
Exactly the way I feel. Some of the WooThemes users don’t even know their way around WordPress…
It’s still weird though though that most of the prominent WP developers considered theme frameworks to be *the* big development in 2009 (according to the Themeshaper post). So I’m not disputing the validity of theme frameworks; instead I just think that the top WP developers aren’t entirely in line with end-user needs.
That’s really cool I—ah, but you didn’t build it using a Child Theme, did you?
Have Foxinni drop me a line sometime. I’m always curious about people’s experience building cool stuff from Thematic.
As far as Thematic, being there, well, it’s at version 0.9. I’ll leave it at that for now. But there’s a reason the number of publicly released Child Themes (and businesses!) for Thematic keeps on growing.
I definitely don’t dispute the awesomeness of Thematic…
But no, we didn’t build it as a child theme, because we didn’t have enough time (which is related to project budget) to teach ourselves that first.
And Foxinni has been notified. I’ll force him to give you some thoughts on the matter. Consider as well that he’s always been a massive fan of Sandbox (which I absolutely hated and *never* used); so his feedback may be different from mine.
That’s my point though… Unless the non-techie can find help on stuff like that from general WP resources, then they’re bound to never understand such advancements.
I know Ian is done a helluva lot for child themes (I’d even be willing to credit him with the idea) and I think that if they go mainstream that they’d be very popular indeed. At this stage though, there isn’t widespread adoption of the functionality – even from developers like ourselves.
Honestly I don’t think that users find much value in specific customisation options like that, since it takes their ability away to customize the theme more extensively (or at least makes it helluva hard).
I can only speak from experiences with our WooThemes users, but even the one’s that don’t really know what CSS is, attempt to tweak it…
Glad to see you’ve got the conviction to back up your ideas. And thanks for the snide little attack there… WooThemes have been at the forefront of many new ideas in the WP theming community and I don’t see us slowing down at present. So I don’t see us becoming irrelevant either.
And a framework stays personalized by the original author; just not in a design-sense. Code is design as well and I’m sure you can find 10 different code snippets to accomplish the exact same thing in WP (with only 1 / 2 being optimized and “right” though). So fact is – the code in the framework is very much an extensive of how that developer thinks and codes. If a framework thus becomes widely adopted, the general WP user needs to also “adopt” the way that developer thinks / codes to fully utilize that platform.
There is no right or wrong with frameworks of this kind; and specifically for that reason frameworks will never be adopted by the end-user (not in 2009 or in future). Maybe a superior framework will emerge in 2009, but it’ll only be used by developers that know their way around WP.
The end-user just wants a theme that scratches an itch; they don’t want a framework to build that itcher-scratcher.
You’re missing the point. And judging from your stance, I don’t think I’ll be able to explain such a new concept to you, but I’ll try anyways. I can only speak for WPF, but theme frameworks are meant for theme authors first, not end-users.
Theme authors build WordPress themes based off the theme framework and distribute their theme to the end-user. What the end-user gets is a fully functional WordPress theme, and they can modify it using best practices if they choose to do so.
It seems as if you think the end-user needs to modify the WordPress theme in such a way that prevents it from future theme updates. For this reason and many others, WordPress 2.7 now has a better way for end-users to modify WordPress themes. It’s called Child themes and you should check it out..
You should consider being less self-indulgent and insulting. This is meant to be an open discussion on where theme frameworks fit in; I know enough about child themes to assure you that you are missing the point of this post.
Re your comment: We all talk differently. My comments aren’t meant to come across as “snide”, or “self-indulgent and insulting”, or anything else you might label them as. That’s just how I talk. Your asking about the viability of theme frameworks and explained how you feel about them. I voiced my opinion, that’s all.
Users don’t have to understand Frameworks to benefit from them. As theme authors, we have the opportunity to offer users a painless upgrade process along with a great theme. But there is a way to make it less transparent to them, so they don’t get confused.
I just feel that such a view is unrealistic. You deal with the end-user at iThemes as well and you should thus know what kinda features get the most support enquiries. Unfortunately bloated code is a guarantee of that.
This is me talking from WooThemes’ perspective; so my opinion relates to the end-user and not the developer.
Adii,
Yes, you are correct. I do develop and support our themes. But if you bundle the Framework + child-theme (the child theme being where the theme CSS is located) and invest in an education process, I think adoption pains would be minor. In fact, we’re counting on it.
I disagree. The Framework + child-theme combination solves a lot more problems that it creates.
Sorry Dan, I should have been more specific. I was disagreeing with your last statement. I do believe they are a end-all solution (potentially). By bundling Framework + child-theme, you are solving a LOT of problems (a lot more than it creates at least).
My ambiguity is my worst enemy sometimes
Well, I’m coming at it from the perspective of users on a WPMU system, where they *can’t* edit themes, even if they knew how.
So those kinds of options pages are quite helpful.
First, thanks for mentioning WPUnlimited.
I am positioning the theme as more of a package for those that don’t want to attempt to edit CSS, as well as reducing the learning curve for those that like to edit their sites. Which would you rather, figuring out my CSS file, and making changes to effect the width, colours and typography, or just making quick changes in an admin panel?
People constantly laud WordPress for adding new features, but every time they do, they only get more popular because it lowers the barrier for entry.
WPUnlimited reduces the barrier for customization and expression, and I think that will be important for many new people to WordPress, especially those moving from another platform, or moving from WordPress.com to WordPress.org.
I think many people that have development and design skills will underestimate the draw of simplistic but powerful control.
While this does increase the amount of code that I have to maintain and ship, the actual bloat on the user facing theme side is minimal and well worth the ease of features added through the administration control system.
Also, WPUnlimited does what WordPress itself does by taking some of the onus on feature development away for plugin authors and places it squarely on my shoulders to make sure that the features people know and love, always work with new versions of WordPress.
Lastly, WPUnlimited, unlike other “theme frameworks” makes use of nearly stock WP Theme templates, meaning that the advanced modification you are worried about is even easier than most other frameworks. This has limited the number of features we could roll out, but improved the odds that someone familiar with WordPress themes can customize WPUnlimited (if they’d rather hard code everything themselves).
What Nathan? You lost me… are you replying to the right comment, because I never said it causes problems, period… or for that matter was a bad idea. Plus my third paragraph summed up what you said iThemes was doing. I think were on the same side here, because I can’t disagree with anything you said in your comment before mine.
I hear you and have a lot of respect for your views in this regard. But…
Consider the 26 themes we have on WooThemes now. If we had to have one, all-inclusive framework (since we cover a wide variety of niches) and 26 child themes; then surely that bloated, complex framework loses its value!?
The value is in the design, though. That (plus support) is what users pay for. And no one says you have to sell the Framework itself. As far as users are concerned, they don’t even have to hear the word “framework”.
All they need to know is that in order for their theme to work, they need to upload 2 folders to their themes directory. They don’t need to know why. They do it because you’re the developer.
I don’t understand how using a framework to build those 26 child-themes would lessen their value. In fact, from our perspective at iThemes, it makes them more valuable because each child theme would indefinitely benefit from the progressively more robust code you build into the framework with each successive update. To get that kind of effectiveness, every time you come up with a better code scheme, you’d have to update every single one of those 26 themes. But with a Framework + child-theme, you make a change to the Framework and all 26 child-themes receive the benefit of the new code.
win-win-win
Okay, okay… I’m not saying that there are no benefits to using a framework + child theme infrastructure, but I’m still not convinced that the cost thereof is less than the ultimate benefit.
From our side, that framework would be helluva valuable, as we’d have one basis across all of our themes, which we can continuously improve and add to. But the more we do both of those, the more complex that framework becomes and the less the end-user can actually interact with that (albeit by making direct tweaks or via a child theme). Fact is, this is very much “PHP-powered” and as @Foxinni noted above, that increases the height of the hurdle the end-user needs to jump to accomplish their desired modifications.
One thing that I truly believe in (and Magnus is the big advocate of this at WooThemes) is to keep things as simple as possible. So my question is… Would 37Signals do this (if they were into WP themes)?
Adii,
I can’t help but agree with you there. Frameworks — even the best frameworks, with the best documentation — are hard to modify. Here’s the process for the framework I’m making.
If you want to change the “read more” text using the new iThemes Framework:
1. Open up your child-theme’s /custom/functions.php file
2. Create a function that returns your custom text.
3. Hook that function the the more_link_text filter
Another proof would be this video, which explains how to change the text in the footer of Theis:
http://vimeo.com/3075621
Is that intuitive? No. Is it as easy as opening up a template file and modifying raw text? No. Is this a problem? Yes.
There is a solution out there, but it just hasn’t been figured out yet.
BUT…
For us, we’re taking a calculated risk. We honestly believe that the support and maintenance headaches this system will solve far outweighs any complexities it brings to the table.
It’s just how we’re planning on doing things. Nobody else has to do it this way. We’re just trying to save ourselves some time and trouble. Maybe it’ll work. Maybe it won’t. But we’re sitting on success, methinks.
And that’s exactly why we’ll wait for you guys to make the jump; so that we can decide which way to go after we’ve seen how things have panned out with iThemes!
Clever business…
Nah, more seriously… I totally agree with you and the only difference here is your willingness to take this calculated risk at this stage and my opinion that it may not be worth that risk. I do however feel that WordPress and its themes still have a long way to go and I look forward to more innovation in this regard.
Frameworks, child themes and what-not are all innovations in my book; whether they will stick is another question… Some of these may fall away completely, but at least they would’ve paved the road to better things.
Actually, having WooThemes on one framework would be heaven for me.
I provide sites to specific industries. We use WPMU. If WooThemes was based on one framework, then I could offer all 26 of your themes (and new ones that are released) and only have to update the one parent. My clients would be stoked and my support of theme updates would be reduced.
I do that now with Thematic where I can have industry specific child themes.
The framework concept isnt necessarily for the single user, although I know a few who would appreciate WP Unlimited. The true value of frameworks for me is what I can leverage with them.
I could create my own framework, but that means more support and basically reinventing the wheel.
Well said on both accounts. I too am intrigued with what Nathan & the iThemes guys are building and look forward to them rolling that out. But I’m still not entirely convinced that this is something that I will look to emulate.
I too like & follow your “blank template” approach and it hasn’t slowed me down once.
Jason, I couldn’t have said it better myself! I also have my own basic template that I can easily update for pretty much any type of project. That’s why I’m able to produce a theme in just a couple of hours, or even minutes.
I guess the best way is “your way”. And it’s not “my way or the highway” for me, is just that I haven’t found a framework / template / naked theme / whatever that helps me improve my work flow.
So until I do, I’ll stick to my trusty “Simple Canvas”.
I could see the majority of people using frameworks in the future. Most without knowing it or just knowing that they need that second folder for some odd reason. But the people who are going to take advantage of framework and build child themes are going to be theme developers and people who make their own theme for fun. The average joe isn’t going to build off of a framework and that’s how its meant to be. Frameworks should do the common tasks and the things developers don’t want to focus on.
I said it wasn’t the end all solution, because I think Adii was seeing theme frameworks as something anyone and everyone could extend and build off of… not necessary, just be using unknowingly, at the very least.
Yeah, I would have to agree.
Would’ve been nice if the comment wasn’t anonymous…
I sympathize with you and completely understand your frustration in this regard. I think however as Nathan has rightly pointed out – there’s a trade-off here and the perfect answer isn’t using a framework or using no framework (there’ll probably end up being a compromise and a balance in the near future).
Also consider – that theme developers can’t be held responsible for changes in the WP core or even less changes to popular plugins. Unfortunately theme developers are dependent on both of these, whilst the WP core (for example) is totally independent of what we decide to do. In an ideal world, we’d never have to do forced updates to any WooThemes because of changes in the WP core, but such is life…
I understand how Thematic would’ve allowed you to bypass these issues in future, but as I mentioned above, a WooThemes framework that needs to support 26+ *types* of child themes (plus multiple iterations thereof) will be bloated – so taking the principles as set forth in Thematic and replicating that within the WooThemes environment is just not viable at this stage.
Wow – your comment is almost as long as my post!
But I have to say, that I totally agree with you with regards to these frameworks becoming a “theming framework” instead. For me however, we (read: the WP community and prominent developers) don’t need to settle on one theming framework, but instead we could settle on 2 / 3 / 4.
So in essence, we’d have a similar situation to having to choose between jQuery, MooTools, Prototype etc. etc. Then it comes down to preference, which I’m more than happy about.
Re-reading your comment, I really think you’ve hit the nail on the head!
Yay! Yeah, I realized about halfway through that I should have just blogged a response myself. C’est la vie.
I think you’re onto something about developers choosing between lots of different frameworks, but I still think that the core adoption or at least promotion of one or two will really spur innovation by newcomers.
I actually think the community solution to the lack of a true templating system, by way of frameworks is pretty clever, and indicative of how importan theme developers are to the future and the proliferation of WP.