Why I Rarely Use Starter Themes

I love theming Drupal sites. Yes, I realize that means I’m a super nerd. Drupal’s theme layer with its system of overrides is powerful. It works so well that I rarely need a starter theme, like Zen, Basic, Framework or NineSixty nowadays, other than as a reference and source of code snippets.

What Starter Themes Do

Drupal 6 saw a jump in the number of contributed starter themes on drupal.org. Now it’s much easier to find a list of all starter themes and there are a few great reviews and a comparison chart. Starter themes are a class of themes that attempt to generalize their features to speed up implementing a design for most any site, while encouraging best practices. They are popular among development teams since they help standardize theming when multiple people must touch the theme. They are also excellent demos of the power and potential of Drupal’s theme system, which makes them a great learning tool and source of documentation. Many starter themes are intended to be used as a base theme, where you create a sub-theme that draws off their files. This makes it easier to produce themes with fewer files and overrides, leaving the base/starter theme to do most of the heavy lifting.

A closer review of contributed starter themes reveals some recurring features, including:

  • sliding door tabs
  • contextual body classes
  • contextual block and menu edit links
  • useful Internet Explorer hacks
  • multi column layouts
  • print style sheets
  • thorough code comments
  • various theme settings
  • content first source order

While print style sheets and thorough code comments are always a good idea, many features present in starter themes are not always necessary on every website. 

Not All Websites Are Alike

It is great when starter theme fits the needs of a project, but they don't always do. For example, block edit links are not necessary if the site relies on panels, or if a project avoids using blocks all together. Very often the overall site layout is unique for every site. As well, the majority of websites do not need the sliding door technique for tabs. Internet Explorer hacks are usually particular to the site layout and CSS techniques used for each website. For layout positioning, I try to use 960 grid systems' CSS techniques and safer IE CSS2 selectors/properties, which makes it possible to avoid most IE hacks and debugging. If we use Panels for multi column layouts, it usually relieves the theme of this responsibility. In the case of content first source order, there is more than one way to achieve this. The 960 grid system makes this particularly easy with its push and pull classes. 

To achieve multi column layouts, themes normally have a delicate interconnected web of template variables and conditional CSS rules based on different body classes. If a theme must house a multi column layout, I would say that feature alone is a great reason to use a starter theme. But within the Panels paradigm, starter themes tend to introduce some superfluous files and code. 

What I Do

I find the most repetitive part of theming is generating CSS for default Drupal elements. These include tabs, tables, menus, form elements, messages, help text and typography. Our Creative Director Nica Lorber and Lead Designer Floor Van Herreweghe shared their Fireworks template approach to theming Drupal, which ensures design attention to core Drupal UI elements. In fact we started to standardize design of these elements to the point that I can reuse a lot of CSS from one project to another in a single reusable drupal-elements.css file. This file, along with a CSS reset and 960.gs is my starting point for most websites.

Just about everything else involved in implementing a custom design is unique to each website. I might create a little custom markup. However, I end up copying and pasting most everything else from past projects and contributed starter themes.

Lastly, it’s just as easy to have a lean and well commented theme within a multi person development team, as it is to use a starter theme. I prefer this over requiring all developers and themers to learn the approach of a particular starter theme in addition to understanding Drupal core’s theme layer. To adhere to web standards and Drupal best practices, I prefer a check list approach and cheat sheets.

Drupal's Markup is Getting Better 

Drupal 6 pulled in many changes from the 5.x version of the Zen theme. Since then I have less so needed to use starter themes. With Drupal 7, there are more improvements look forward to in Drupals default markup. Contributors to Drupal 7 put a lot of effort into making its markup as beautiful as possible. If you look at Stark in Drupal 7, the only theme files in it are a layout.css and stark.info. They did this to demostrate the minimum requirements to create a theme, and to provide a theme that shows off Drupal 7’s sexier HTML. To modify markup in Stark, one would simply copy over some template files, like page.tpl.php or node.tpl.php, edit them and clear the cache. 

It might be that if Drupal's markup was perfect, we wouldn't need starter themes. But the fact that there are so many seems to mean that we have different needs for a starting point for building new themes. It also reflects the fact that Drupal theming has needed better documentation. Fortunately that documentation is getting a lot better and hopefully we can look for ward to more people jumping in and learning theming. 

Topics