Why We Advise Against Most Starter and Base Themes

Drupal theming with Tao

I recently gave a presentation about performance and scalability at one of our local Drupal meetups here in Shanghai, an got confronted with questions on Drupal theming and more particularly the type of starter theme we use here at Wiredcraft. Well, the answer is quite simple; basically, we don't, at least not the major ones. No Zen, Omega or Fusion, no custom base theme either or CSS framework such as 960 Grid. What we do systematically use though is Tao; let me explain...

Why don't we use starter themes?

I believe that starter themes can be interesting in a couple cases;

  1. It can help beginners get started with Drupal theming by setting up a lot of defaults for a somewhat overwhelming number of elements you need to get familiar with.
  2. It can provide administrators with a quick way of adjusting layouts; combining Panels and the 960 Grid (using the NineSixty theme) can be an interesting approach, allowing for easily adjusting the layout by simply assigning classes to panes. However, while they may prove useful through the designing and prototyping phases, grid frameworks create semantic issues and can be very rigid to deal with. Moreover we never, ever use Panels; we're Context guys and have been from the very beginning.

The problem is, we think that for experienced Drupal developers there are quite a few drawbacks to these starter/base themes;

  1. They tend to slow down developments by adding another layer of complexity; additional APIs, functions, "hooks"... I can't remember the number of times I struggled with a very straightforward preprocess or theme override in a theme because Zen was adding some "helper" functions around things.
  2. They often introduce bugs or incompatibility with some other modules (Zen with Context for example) as well as performance concerns. All that sugar-coating has an overhead that can be very costly; we quite regularly do performance audits of Drupal sites and haven often advised for a complete rewrite of the theme.
  3. Our opinion is that more often that not they lead to poor practices (or at least enable them), the biggest one being the proliferation of template files and CSS spreadsheets, instead of relying on preprocessing and properly thought through layout and styles. How many times have you open a custom theme folder to find an insane amount of views-view--XXX-block.tpl files?

We're suckers for Tao!

We have been using Tao as a base theme since the end of 2009. I am unsure as to why, but many people either don't really acknowledge its existence as a full blown base theme, or don't really understand what it does. Maybe this has to do with it having been hosted on Github in its infancy, or the fact that it was mainly built as a dependency of Rubik (an admin theme that we've shipped with all our sites since its first release, give it a go...).

What Tao does really, is dealing with the bulk of the issues anybody has with Drupal theming. Let me paraphrase the project page here to list what it does (well);

  • Resets browser and Drupal core default styles (die admin.css),
  • Unifies the template family into a consistent format (node.tpl.php, block.tpl.php...)
  • Various other small fixes and bonuses, such as a proper print stylesheet or theme overrides for fieldset and pagers.

In brief, it gives you a solid, clean foundation both in terms of CSS and HTML to build a theme upon.; if you stick to it and leverage the power of preprocessing functions, you should be able to build leaner and more robust Drupal themes. We strongly advise anybody doing Drupal theming to give it a try; we've already converted quite a few clients and partners to it.

But...

This approach has been really rewarding for us in the past couple years, the only thing is that it does require you apply the same type of concepts to your design approach; we believe that building lean, simple, information oriented interfaces is the way to go, and if you do so, your graphical concepts should translate properly with a Tao based approach. But that's a whole other discussion.

By Ronan Berder on Jun 24, 2011

Comments

By Corbacho (not verified) on Jun 24, 2011
I agree on some points. Last week I tried Omega and omg, it's a parallel universe of theming. Maybe more suitable to non-developers who wants to have high degree of control via admin UI... but it adds a layer of complexity. On the other hand, the future looks different: Tao is not updated since 2010 (Development Seed left it on Phase2 hands if I'm not wrong) and Omega it's gaining momentum.
By ronan on Jun 25, 2011

That could be a concern, however the very fact that Tao is simple and straight to the point makes it that there will be probably few releases. Moreover, Phase 2 took over Open Atrium and Managing News a mere few months ago and is still probably working through getting up to speed with maintaining the sheer amount of pieces that made it (which includes Tao, but also Features, Context, Feeds, Strongarm...). Give them a bit of time and they will probably get things moving.

By Greg (not verified) on Jun 24, 2011
Some interesting points. One thing - I would have to disagree having lots of TPL files is poor practice. Leaving them lying around is poor practice, because they can be nested in any directory structure - there's no need to dump them in the theme root. But I raised a similar concern right back at the start of Views 2 with Earl himself, and he pointed out TPL files are cached anyway, so having many really makes no appreciable difference to performance once the cache is warm. For me, poorer practice is preprocess functions in template.php - coding in the theme...? No!
By ronan on Jun 25, 2011

Performance is not my main concern here; caching is always an option (or a default in that case), however maintainability suffers from the multiplication of template files.

By David Eads (not verified) on Jun 25, 2011
But that's what preprocessors are for! A last line of data manipulation before you render HTML. Also, custom themes with many tpls (I've seen some with dozens) are a nightmare to maintain.
By Greg (not verified) on Jun 25, 2011
Preprocessors, sure... IN MODULES.
By ronan on Jun 25, 2011

Well, that's again a point of view. I can see how relying on the preprocessing approach can be daunting from a Web designer/themer point of view; Drupal theming has always been a bit geekier than, say, Wordpress, but I actually don't agree with some people who think that it makes it inferior. Preprocessing and override mechanisms can be your best weapon and these are definitely not to be limited to modules; the theme of this very site is based on Tao and uses only 1 template override (to change the place Drupal messages are displayed) and 10 (small) preprocessing functions in template.php.

By firebus (not verified) on Jun 27, 2011
i don't see how having a big mess of preprocessor functions is any more maintainable than having a big mess of template files. my feeling about preprocessor vs. template is that the template file is where the markup goes, and the preprocessor file is where the data manipulation goes - if you have a messy theme, you'll end up with too many of both! if you have duplicate markup in your template files, or duplicate code in your preprocessor, it's possible to refactor the redundant code (this creates even more templates and functions but paradoxically improves maintainability!) i think the thing that prevents this problem is ronan's suggestion to use "properly thought through layout and styles". and i think it's true that having a complex base theme makes this harder - the more sugar there is in the base theme, the harder it is to do your own thing without introducing a lot of kludges. but that doesn't mean that using a minimal base theme necessarily makes it easy to find an elegant solution to a complicated UI. if ronan (or anyone else!) has good techniques to share on maintainble theme architecture, i'd love to hear them!
By ronan on Jun 28, 2011

I hope to publish a follow up some time next week.

By David Eads (not verified) on Jun 24, 2011
Yes, yes, a thousand times yes. This is excellent advice and I'm always surprised to find resistance or confusion when I've suggested this approach in Drupal circles. Really, you'd rather have the complexity of Zen or Fusion over simply writing clean markup and clean CSS?! The other thing about this approach is there's nothing stopping you from doing fancier stuff once Tao has taken care of smoothing out some of the weirdness in Drupal's theming layer: I have several sites in production that use Tao + a custom grid built with Blueprint's compress.rb script (but not the rest of Blueprint). On current projects, I'm using Tao as my subtheme + a custom grid + Less CSS. My current approach has led to easily the cleanest, most maintainable theming I've ever done. Ultimately, the problem with non-minimal base themes and Drupal's internal markup is that they are WAY too opinionated. I just want to write clean, domain specific markup, and then style it. Anything else winds up just getting in the way.
By Matt Farina (not verified) on Jun 24, 2011
I have some questions from some of the generalizations in the post. You talk about performance being an issue. I know for some base themes this can be a real problem but for others it isn't. Have you done any performance research to see how this works out in practice. I know developers like JohnAlbin (the Zen theme guy) takes this seriously and can speak to specific performance impacts and where Zen fits into this. Having seen measured performance data of base theme impact I find this broad generalization to be out of place. But, I'm wondering if you see something I have not. What observations support your theme performance? In the case of the Zen and Context conflict calling Zen out as the issue is misleading. Context was implementing a function meant for themes to implement in order to do what it's doing. Context was crossing a boundary because there wasn't another good way to do what it does. This is a function any theme could end up implementing and is not a unique situation to base themes. Putting the blame on base themes for this is really out of place. Generalizations like "They tend to slow down developments by adding another layer of complexity" negates that they make development faster for a lot of people because they know this additional layer well and use it well. Some people can developer themes much more quickly using base themes. On a time and effort scale on projects this can and has been measured. Overall this post looks to include a lot of FUD towards base themes that aren't Tao. A much better approach would have been to show how Tao is better than other base themes rather than to provide FUD, generalizations, and poor information to try and make other base themes look bad.
By ronan on Jun 25, 2011

I don't doubt that some people get to leverage some of the advantages of the base/starter themes I mentioned, I am merely stating that for people knowing their way around preprocessing and theming overrides and willing to put a certain structure in the design process, Tao can be an tremendously efficient tool by its simplicity. When it comes to benchmarking and further demonstration of use, I well intend to expose things in two future posts, but rest assured that this come from experience and not gut feeling, working with our clients; CNN, the UN, Axel Springer and Popcap Games to name a few.

By Matt Farina (not verified) on Jun 25, 2011
The tone was set in the title of "Why We Advise Against Most Starter and Base Themes". The tone not about selling Tao but instead generalizing about things that may or many not be problems in other base themes. That's not a positive way to approach a post. That creates a certain level of FUD (Fear, uncertainty, and doubt). The post isn't about showing people a great option but making them fearful of some of the options out there. If you are going to turn this into a series of posts to help people make good choices then explain that. Say things like, "in our observation and testing we found Tao to performance better than the other base themes we looked at". If you are going to elaborate further in another post say that. Additionally, When a module like Context does something changes the core API (http://bit.ly/iNXbnk the code in question) the module should be looked down upon, not any themes that override a standard theme function. If anything, when a theme like zen takes the time to recognize the special case context created and works with it credit should be given (see http://bit.ly/jKi52i). Please try to give the next post a more positive and useful tone from the start.
By ronan on Jun 25, 2011

I beg to differ; I fail to see how this tone is supposed to be FUD. We honestly advise our clients against these base themes for, mostly, the reasons I mentioned in my post. You may see some of our points as generalization, because that is somehow what I was trying to outline; the higher perspective on why we approach things with a lightweight base theme like Tao. These points are backed up by personal experience over the course of several years of Drupal related development; some people successfully use Zen, the same way that some people use Panels (instead of Context), SVN (instead of Git) or chose to ignore tools such as Features, Strongarm, drush make and instlal profiles... I am fine with people having a different approach, the bottom line is that it does not work for us and I'm merely exposing my point of view on things.

By nigel (not verified) on Jun 25, 2011
It wasn't FUD and there was nothing wrong with your tone. I scratched my head half an hour wondering what had upset Matt so much. The task of transposing a design to someone else's html and css doesn't make sense to me. It revives however obliquely those horror memories we all carry of discovering a predecessor's mess* and having to come to terms with it. It means hacks at best or at worst painstaking dismantling - at which point you might as well have started from scratch. It doesn't make for clean code. I realise base themes have their advantages, particularly for rushing developers or the css/html-shy, and I also realise they are often elegantly coded in their own right (zen and adaptivetheme in particular). But using them, you're still taking someone else's structure and css and having to mould and wrestle it to your own. That said, it's important to acknowledge most people in this community aren't designers (it's a sweeping generalisation, but true) with a good few who approach their designs without mockups and edge towards something acceptable. Base themes are perfect for this method. *which isn't to suggest that base themes are messily coded, as I hope I made clear later.
By tgroff (not verified) on Jun 24, 2011
Hi, while this article makes a great point about base theme/starter theme performance and best practices, I don't think Omega should be lumped in with Zen and Fusion in the context you've put forth, specifically - in my experience Omega has not; "slow down developments, introduce bugs or incompatibility with some other modules, lead to poor practices". Those are strong words and are not true of Omega as it has allowed me to cut my prototyping and design time by more than 50% because the prototype IS the design ultimately when I develop with Omega. Omega 3.x output is as lean by default, and can be leaner as you so wish, and it fits these other criteria you have mentioned:
  • resets browser and Drupal core
  • eliminates admin.css with the click of a checkbox (can also disable 20+ other stylesheets if you wish)
  • makes proper use of preprocess functions
  • Omega/Delta uses Contexts
I've also never had a need to touch an Omega 3.x tpl.php file. The only thing I see here that Omega does not yet offer is a print stylesheet. It also offers many other features such as HTML5, flexible grid, custom grid based layouts, debugging tools, and toggling of elemets such as Messages, Action links, Tabs, Breadcrumb, Page title, Feed icons. Sorry to sound like an advertisement for Omega, I'm just a loyal user, and think the criticisms of base themes in this article are not applicable to Omega.
By ronan on Jun 25, 2011

I can see your point regarding the Omega theme, we may not have made justice to it by bundling it along with Zen, Fusion and the likes. Tao however has been around for a good little while and is, as I said, pretty much straight to the point. I don't intend to necessarily systematically blame Omega for introducing performance or compatibility issues as such, just that the overall approach of relying on a fairly large(r) code base for building your theme is not something we favor based on our experience.

By Cleaver Barnes (not verified) on Jun 24, 2011
The reason I give for starting with a base theme is simple: security. After taking in Greg Knaddison's Drupal security session in San Franscisco, I learned the number one way to introduce a security vulnerability in Drupal is through the theme layer. There's definitely cases where you'll want to go with something leaner, but in most cases something like Zen or Fusion is your best bet.
By ronan on Jun 25, 2011

I don't fully agree; from my own experience, most of big security gaps come from things that happen in the templates files directly, things like displaying node fields straight from the node object in a tpl file, short-circuiting any type of filtering that Drupal is supposed to do. Stick to preprocessing and you should be fine; that's exactly what we do with Tao as a base theme.

By Damien McKenna (not verified) on Jun 24, 2011
I'm confused - on one hand you say that "base themes suck" and then say you love using Tao, a base theme?
By ronan on Jun 25, 2011

Alright, the headline may be slightly tangential, but the introduction addresses that (IMO): "at least not the major ones. No Zen, Omega or Fusion, no custom base theme either or CSS framework such as 960 Grid".

By Zachary (not verified) on Jun 24, 2011
I do not mean to sound provocative or oppositional, but would you be willing to make an example of a custom subtheme made with Tao, and offer a bit more instruction? I am currently using Omega and it is overly complex. However, I have many pages that need different layouts, and the user needs to adjust them. So, how would Tao solve that?
By ronan on Jun 25, 2011

I am not entirely sure of what you mean when you say "and the user needs to adjust them", but I would recommend you have a look at Context and Tao working together; you have the ability of defining classes that are caught up in Tao as well as defining contextual layouts. We've been using it on a couple sites and hope to describe more in details this, and other details related to Tao, in a post next week.

By Grayside (not verified) on Jun 26, 2011
Examples of subthemes of Tao: Rubik, Open Atrium's theme Ginkgo and the simple theme I've only seen associated with a Feature Server install profile, Singular. I think the argument that base themes add complexity and slow down development doesn't make sense. Good complexity requires learning, but once mastered is empowering. The Views module is a great example of empowering complexity. I agree that Tao does some stuff that should really be part of core. For example, it massages the input format selector into something both better looking and easier to target with CSS selectors.
By Ouick (not verified) on Jul 26, 2011
http://www.ouick.com/meizitang
By Tai Travis (not verified) on Aug 18, 2011
My first Drupal6 site was built with Starkish. Tao looks like a similar approach to theming as Starkish. Another I was considering using is Mothership. Bloated themes like Zen and Fusion are appropriate if you are flexible with the outcome and plan on minimal customization. They can be very inefficient if these things are not true. I think that we should differentiate between a starter theme, like Zen and Fusion, and a base theme like Tao, Mothership or Starkish. Regardless, there are brilliant ideas in all of these themes that you can implement when you are designing your next Drupal site. Tao looks great, thank you.
By Stephen (not verified) on Aug 18, 2011
Hey i noticed that Corbacho expressed some concern that Development Seed's exodus from Drupal might render Tao out of date. Certainly there are several patches (as well as unanswered support requests) kicking around in the issue and bug queues. My question is this: would it be possible/desirable for any of you good folks at Wiredcraft to gain maintainer status of the Tao project? Seems like it might be a win-win for everybody! :o) But if not, is there reason to think that Phase 2 will bring Tao up-to-date? Although it's easy for me to say as a non-developer, i can't help but be concerned that Tao might remain stuck in 2010, despite the many who do employ it as their default starter theme. Thanks for any insights.
By Stephen (not verified) on Aug 19, 2011
I somehow supplied an incorrect email address in my previous post. I've corrected the mistake in this one.
By Kalinda (not verified) on Oct 14, 2011
Ok, sounds like some good arguments for no base theme. I've really grown accustomed to using LESS for CSS lately. Any thoughts/objections there? I've experimented with both SASS and LESS and found LESS to be cleaner, leaner, and much more CSS-like (and therefore more designer-friendly). The trick is coming up with a good workflow. I've been using Less.app for Mac and it makes for a pretty seamless process. My only thing I think we should NOT do is use the LESS module. Compiling less on the fly can have some benefits, like DOM variables, but I hate to risk WSOD for something like that.
By ronan on Oct 17, 2011

I've used SASS and LESS a couple times for some experimentations of mine; I've never used them on a professional site though. I like the idea, a lot, the same way I like CoffeeScript, I've just never seemed to find a really compelling reason to switch to it though.