by Jeff Eaton on January 26, 2009 // Short URL

Designers, Drupal, and the Future

First, a disclaimer. It's been a long, long time since I've done real design work for the web. (One of my earliest sites is still standing, a monument to the days of hand-optimized GIFs and table-based layouts...) I'm not a CSS guru, and I tend to get frustrated quickly when I leave the world of code and muddle into the cobwebbed design parts of my brain. I do my share of converting existing themes and CSS/HTML templates to Drupal, though, and I chat with enough Joomla!, Wordpress, Movable Type, and ExpressionEngine folks to have a few thoughts on what's up in Drupal Theme Land.

The Past

Drupal has long had a reputation for baffling designers, and for years it was deserved. First, Drupal's approach to generating an HTML page is a bit different than the standard Wordpress/Movable Type approach. Rather than asking the CMS for a piece of data and doing things with it, a Drupal theme is handed small pre-rendered chunks of text (like a title, an author's name, etc.) and is responsible for 'wrapping' them in the appropriate HTML markup. It's a subtle difference, but it requires a shift in thinking.

In addition, making a custom theme for Drupal that deviated from the normal markup in a significant way used to require nontrivial PHP skills. While the big pieces (like the page-level markup and individual pieces of content) could be tweaked using editable template files, overriding smaller bits like navigation menus and the details of a post's attribution line required wading into the depths of Drupal's theming APIs and writing code. If you remember the days of the _phptemplate_variables() function, you know what I'm talking about. In addition, changing markup created by third-party modules required digging through the source code, finding where they generated their HTML, and implementing your own override functions in PHP. It worked, and it didn't require hacking third-party code, but it was hell for folks whose comfort zone was pure HTML and CSS.

The Present

Thanks to some awesome work in Drupal 6, a lot of those hassles are in the past. More markup now lives in editable template files instead of PHP functions, and third-party modules can expose their own markup as editable template files. Developers on large projects coordinating with designers can use hardcore PHP code to finesse data before it makes it to the template files, but the templates still say clean and easy to edit. It's also possible to build "pure" CSS themes that rely on Drupal's default markup.

The down side, though, is that not many people outside of the Drupal development community know about these changes. The information is there in Drupal 5 to 6 changelogs, and there are bits and pieces of knowledge scattered in blog posts and articles. The little-known but information-rich Drupal 6 theming guide also helps. However, the fundamental shift in Drupal design that took place hasn't resulted in an new wave of non-programmers designing for Drupal.

Some of that is inertia -- it's "well known" that Drupal is hard for designers, the same way that it's "well known" that it's impossible to make accessible Joomla! themes. (Both have been true in the past, but that's changed -- witness Beez.) Part of the problem is also cultural. Drupal requires that designers learn to use CVS for version control before contributing their work back to the community. Addons and themes the live outside of the downloads section tend to languish in obscurity, like books that can't be found on

The biggest issue, though (at least in my opinion) is the lack of good theming examples in the Drupal core download. Developers looking to learn best practices can pop open any core module, poking around to see how things are done. While few are perfect, they demonstrate lots of useful techniques and can be used as starting points for almost any project.

Drupal's bundled themes fail on that count, in a big way. The default Garland theme, while attractive and customizable via the admin interface, is notoriously confusing for newcomers to use as a starting point in their own custom designs. Older themes, like Bluemarine and Pushbutton, are holdovers from the days of tabled layout and 2004 era design. None of the core themes demonstrate the capabilities in Drupal 6: CSS-only themes that use the 'default' markup, easy creation of new content regions without custom code, and the use of template files to override lesser known HTML like the poll module's graph of survey results.

When Lullabot teaches its workshops on Drupal theming, we've found that taking people through those steps is one of the best recipes for success. Start with nothing but an .info file, to define a theme that uses the default markup and no CSS. Start adding your own CSS files and images to customize the layout, and then begin pulling over templates like page.tpl.php when you find that the markup needs tweaking. Eventually, we can lead them through the complexities of template.php code overrides, but this progression makes for an actual learning curve rather than a wall that needs scaling.

The Future?

Drupal 7 is still under development, and a lot of energy is crackling around how to improve the bundled themes that come with it. Several people have proposed using a grid system like 960 to enable rapid theme development. While I'd love to see some cutting-edge CSS coolness make it into core, I think that we need to ensure that the basics are there, too.

What would I love to see included in Drupal 7?

  1. Make sure all of Drupal's tpl.php template files contain usable, standards-compliant markup. This came a long way in Drupal 6, but there are still a couple of rough edges. Content-first ordering in the default page.tpl, for example, would be great.
  2. Include a layout.css file in Drupal's System module that does nothing but position the header, sidebars, and content correctly. Overriding these core CSS files is easy; just add a CSS file with the same name into your theme. For newcomers, though, it would help clarify how the default template files work in a minimalist layout.
  3. Provide a core theme that is nothing but an .info file. With default markup and a layout.css file provided by core, this theme would serve as an example of what "stripped down Drupal" gives a designer to work with.
  4. Provide one or two core themes that are only CSS and images decorating the standard markup. This has been done in contrib for Drupal 6 (See dvessel's Skyliner theme), but very few realize it's possible. If we discover that Drupal's default markup isn't flexible or clean enough to theme with pure CSS, we should fix it.
  5. Provide a theme that adds one or two additional content regions to implement the newsier appearance that's common in Joomla! and advanced Wordpress themes. This theme should also override one or two of the less common templates from a core Drupal module: user-profile.tpl.php is one possibility, as few realize it can be tweaked so easily.
  6. Provide a theme that uses template.php code overrides and/or jQuery to implement exotic functionality. This doesn't have to be insane; it could be as simple as turning one region into a slide-out panel using jQuery, adding daytime and nighttime CSS, or adding extra "template suggestions" so comments by the author of a post show up differently. The important part is to point people in the direction of advanced techniques.
  7. README.txt files inside each of these themes' directories should explain what they do and how. (Regions are added by putting a line of text in a theme's info file, module templates are overridden by copying a tpl.php file into the theme's directory and editing, etc.)

Can it be done?

This is a big set of wishes: it implies at least two completely new themes for core, with specific requirements. If we were to hit those goals, though, I think we'd have a much better collection of examples to point designers to when they learn the Drupal ropes. In addition, designers exploring a new Drupal install for clues would have something to go on before they start posting confused questions on the support forums.

So, what do you think, fellow Drupal developers? Can we make this happen? Even more important... should we?



Definitely. Enlist TNT

As a developer and a intermediate CSS dude, I like to be able to work with something that is clean or gets me 65% there, and then I start to tweak.

The Acquia Marina theme (and a lot of the TNT themes) do a great job of breaking down their themes.

Their README's are great, the customization is awesome....I know....I know, I sound like I'm their PR person.

Seriously though, I think it would be good to enlist their help in bringing some clean starter themes for true designers to tinker with.



Great Goals

These are really great goals all around Eaton, and a BIG Kudos on them. I know we've discussed these in IRC, but it's nice to see them clearly painted here in an easy to understand format.

If I could expand on these ideas just a little:

Drupal's core output needs to be absolutely amazing. xhtml 1.1/css 2.1 compliant all around, with the ability to quickly and easily do pure css themes. Zen buys us a lot in this regard already, and I know there's a movement to get zen (or as close to it as possible) as the default output. I would heavily support this movement as we could easily put together a site that is dedicated to Drupal theming and have a whole section of just css theme guides. This would reduce the barrier to entry greatly, and I think the process of teaching you outlined for Lullabot could be implemented on such a site with great ease (easy today, easier in 7 if all goes well)

That is probably a "killer feature" list addition IMO.

Beyond that some "Progressive Enhancement" techniques to make sure that css sheets pertain to the individual purposes, instead of a catch all css sheet anywhere would be good. This is by no means mandatory, but could help again in understanding what's possible, and would allow Drupal to potentially supply a number of different great base css sheets for various purposes (imagine two text.css sheets, one for serif and one for san-serif fonts, allowing the designer to get nice professional text settings based upon the sort of look the site needs. They could just copy one of these and use it, and have rational starting points for all their text on the site, w/o needing to worry about various nooks and crannies of Drupal's administration). Your mentioned "layout.css" is very similar in concept to this, and zen takes this further by using 100% layout, and a fixed width one.

Anyway, all around I'm VERY excited about trying to help make these changes get into D7. I'm also a big proponent of seeing make it in, as I think this would give us additional credibility with designers, and push a really great grid system.

Kris Vanderwater


Nick Lewis

Autogenerated tpl.php Files With $vars Documented + 960 is good

I think the views 2 module is on the right path in allowing you to grab default template files, with autogenerated documentation of the available variables at the top of the file. It also gives you all the possible hook-[%wildcard].tpl.php suggestions.

The guys working to get the 960 theme are on the right path too, imho. A lot of designers think *drupal is hard* when in fact *html and CSS* are hard. I use blueprint (similar to 960) for every project. Once you get used to the naming convention, building themes without it is like writing javascript without jquery: big-freakin-pain-in-the-ass. You don't have to be a web designer to understand the system either, you just have to be able to add, subtract numbers... (this may be a roadblock for a few designers I've met...)

I totally agree that theme_page needs to be fixed into something not so terrible.



No non-theme (engine) css please

Include a layout.css file in Drupal's System module that does nothing but position the header, sidebars, and content correctly.

I confess I cringe at the thought of perpetuating the practice of Drupal core generating css. Even the concept of "header" and "sidebars" is unsemantic, and comes with a whole host of assumptions that simply may not apply in many situations and should not be assumed as defaults to be overridden.

Rather perhaps a better approach would be to have a core web theme upon which other themes can optionally be based -- said theme containing the layout.css and sundry other "default" stylings that can be optionally overwritten.

Keeping this in the theming layer removes assumptions about presentation from the business logic and content storage. With various non-web forms of content consumption proliferating and evolving at an ever-faster pace these days, it seems that the only presentation logic that should be generated by the system is semantic mark-up presented in descending order of importance. Let the themes do layout and the rest.

I love the rest of the ideas in this post!


Marc Robinsone ...


The concept of ".info"-based theme is really thought-provoking in a lot of ways.

The simplicity can drive other content management systems to go crazy!

Oh oh oh, not to mention the possibility to create a "theme generator" or "theme builder". I can imagine clients picking color schemes, adjusting layouts, and branding a theme right on their finger tips.

Maybe someday, this will pave way to easilty "plug-in" or integrate other cool open source interfaces (such as EXTjs, Flex, OpenLaslo etc).

I can't stop imagining -- and it's your fault Jeff Eaton. ;)

Huge thanks to Lullabot!



hunting for .tpl.php files

Having everything split up into .tpl.php files is nice, but then having to hunt for the modules that have them can be frustrating - I may know that the place to look is /modules/system or /modules/node, but does a designer?

I think having the core templates in one directory (as the phptemplate dir with Drupal 5) makes a lot of sense, you immediately see what's there to choose from.


Wim Mostrey

Devel module

The devel module comes with the Theme Developer module which works like a Firebug. It will show you all the function names you can use to alter a piece of content, or what files you can alter or create.



The search for tpl.php

I actually keep a 'starter' theme directory with my other Drupal tools, for when I'm porting Wordpress themes and CSS/HTML templates. It contains an info file, and override of system-menus.css, and a folder called 'templates' that contains every tpl.php file from core. As I decide I need them, I can copy them out of that directory...


Robert Douglass

Theme sprints?

Since we're getting pretty good at achieving leaps and bounds improvements through code sprints, maybe we should plan a couple of theme sprints to implement this wishlist. I know I'd put money into the Chipin for this.


Wim Mostrey

Drupal Zen Garden

I absolutely love item 4: "Provide one or two core themes that are only CSS and images decorating the standard markup." One core theme should probably be enough to showcase this and to lay the ground for a Drupal Zen Garden.


peach - all dru...

good ideas

Most seem like good ideas, but I think no themer is waiting for a layout.css that tells them how their columns should be positioned. Different CSS methods use different ways to position structural elements.

I really would like to improve the theme engine, the color module and the core themes for D7 but for the next 2 months theres no way I can make time.

I would also like to see if there is a sensible way to integrate the block-theme module with drupal 7 core

Also, Im personally not a fan of CSS frameworks because after 5 years of coding CSS you've pretty much developed your own framework and your own coding style. Though standardization is something that has always been valued highly by backend programmers and maybe it would add value to frontend code as well, but thats something I cant decide on my own.

When I launch the premium themes on theres going to be a lot of new open source theme code that should really be in core, so I hope there will still be some time.




Most seem like good ideas, but I think no themer is waiting for a layout.css that tells them how their columns should be positioned. Different CSS methods use different ways to position structural elements.

I agree -- the idea isn't to show experienced designers how to do CSS positioning. Rather, it's to provide a quick and easy way to check out Drupal's core markup and CSS -- the stuff that you'll be working with and potentially working around when you make your own theme. Keeping the positioning CSS extremely simple isn't an attempt to teach people positioning, but an attempt to ensure that we don't get sucked into decorative flourishes with a theme that's just about showing the skeleton.

I really would like to improve the theme engine, the color module and the core themes for D7 but for the next 2 months theres no way I can make time.

Are there any specific improvements you think would be a boon to designers? Even if you don't have time to dive and and implement them yourself, this can be a great time to brainstorm with others and see if they can get on the agenda.




I agree grid based themes are not a one size fits all solution.

As a themer I tend to use my own "default" styles, but I think we would benefit from improved html in core. Drupal already does a good job at outputing clean html, but it still can be better.
Specifically, I love how Zen adds classes for the body tag and nodes and think this should be in core (I can even imagine how a contrib module with plugins would enable us to add even more classes, maybe with tokens and other useful stuff).



pure semantic output

Hello everyone. I am a designer who is very new to Drupal (from Dubai). It's been a week, i could install D6 and tried CCK, Views, Pathauto and Image Cache apart from core modules. Also i could also grasp the drupal concept of Node, Block and Region. ( I have used Wordpress and EE before for a couple of projects.)

However, theming in drupal is a bit overwhelming. We would love to see some control over the module or views spitting markups. (extra divs, spans and classes). I know that we can override these with templates, template naming conventions and other drupal methods. Most of the designers might want to come with their xHTML and CSS files and add template variables, and function to it instead of tweaking existing Themes (garland, zen). We would like to see a simple custom layout (CSS based Layout) Tutorial in future Theming Documentation.

I think implementation of CSS frameworks should be secondary, most of the time these are personal choices. I hope these feedback from a beginner (or outsider) helps you guys.




The input from someone outside the Drupal developer hive is definitely appreciated.

We would love to see some control over the module or views spitting markups. (extra divs, spans and classes). I know that we can override these with templates, template naming conventions and other drupal methods. Most of the designers might want to come with their xHTML and CSS files and add template variables, and function to it instead of tweaking existing Themes (garland, zen).

When I'm porting templates to Drupal, that's the approach that I favor as well -- start with the XHTML/CSS, and start putting print statements in to putout the Drupal-specific data.

One of the difficulties for modules like Views and CCK is that lots of people want to attach rich CSS to the fields and displays that they output without making override template files, and giving everyone enough markup to attach to requires heavier HTML. I'd love to figure out if there's a better compromise for this. It's not something we can solve in core, because CCK and Views are their own third-party projects, but we can certainly try to set a good example, and figure out solutions for the "easy to skin vs. lightweight markup" struggle...



Great article! This got me

Great article! This got me thinking. It doesn't seem all that long ago but when I started theming I had no programming knowledge and the wrapping of chunks of markup was especially confusing. Theming calls enclosing even more theming calls were really baffling to me. I had to take the long route for it to eventually hit me and go "Aha!".

A shortcut can be made in the form of a pdf cheat sheet. Diagrams outlining the scope of all the common theming hooks and how they fit into the big picture. Devel module gives a peek into this but the pdf could make it even more effective. Include it with a starter theme all prepackaged to flatten the curve. Most theme designers are visual, right? Having it in that form would be easier to take in. README.txt's are less efficient.

Also, I think there's a good reason why pure CSS themes in Drupal didn't take off. The exposure on Drupals capabilities is one as you mentioned. The other is that it tends to be a big hinderance. If you have a specific layout in mind, more often than not it becomes more of an academic puzzle on how you'd have to trick the CSS into shaping your layout. It can be fun to do for the CSS gurus but in real world situations, it's a lot of effort for little gain.


Tao Starbow

How about a Drupal 7 theme contest?

It seems like the other CMS's are always having theme contests. For the price of a couple hundred buck, they get a cool theme, and lots of people trying out building themes. And maybe some of them find out they like it and keep producing.



Also a Mobile Theme

Thanks for writing this up. I think we definitely need to see some serious growth in this area.

I think a theme for mobile devices should also be included. This would serve as a simple example, but also be unique in certain ways and perhaps more importantly open up people's minds to further potential.

I also think a theme contest run by the drupal association sounds like a neat idea.


Drupal on Mobile


I’ve recently started a blog,, which all about making and testing mobile websites with Drupal. I’ve also added a section which summarises mobile modules available for Drupal, which I hope people will find helpul.

Please have a look and get in touch with any comments!





Why not just start by creating a contrib theme with only the target page.tpl.php that could be included in the core and several (>3) layout#.css files.

By just changing the # of the css file in the .info of the theme you could just completely change your layout.

Ex :
* layout1.css : 3 %column --> Sidebar - Main Content - Sidebar
* layout2.css : 3 %column --> Main Content - Sidebar - Sidebar
* ...

Then you could create sub-themes, adding fancy graphics and typo style...

This would be easy, and show the power of the concept...

Then you move the to core, then you move one of the most simple layout.css to core...


Jeff Thompson

Here's a minimal CSS theme...

Here's a theme that I hacked together that uses only a single CSS to outline the major DIV sections of a Drupal page:


I would think it would help a designer start to understand what can be done easily using only CSS.



No. 3 (and No. 4)

I think the idea of number 3 is great. We have been designing and building css based sites for some time now. Many of these have been static sites where we have tried our best to be obsessive about super clean source code before we even touch the CSS.

The idea of having a theme that puts out nothing but the defaults makes so much sense, even if it is to help narrow down which bits of Drupal's default code is not as good as it should be and helping to improve on them.

We have started working on our own clean theme where we are taking the approach of theming everything that Drupal core puts out. Just to see how much work is involved, we've hit 40 hours already! I'm really into the idea of Drupal having nothing but pure clean starting point output html and would love to help out any way I can to get involved.

thanks for the article.



Overriding system.css?

Overriding these core CSS files is easy; just add a CSS file with the same name into your theme.

Did you mean:

  1. Simply placing a file named system.css in my theme folder and listing it in the .info file will prevent the default system.css file from loading?
  2. Or that system.css file in my theme folder will need to contain overriding styles because the core system.css file will still be loaded?

Please be #1. Please be #1. Please be #1. Great article by the way. I'm glad to see this discussion happening.



Already does #1

Yep, D6 already does #1 by removing the system.css file version served up by core (or any other core/module stylesheet) if you name it in your file and create one to replace it in your theme.

Here is the documentation page for this behaviour:



Lack of "ordinary" solutions

I think, scarcity of good drupal themes is the most important reason of choosing Wordpress or Joomla, because for most users will not understand major differencies between these cms (I mean - they all worked and worked well!)

I personnaly was really impressed by such number of great wordpress themes! I even thought about moving my site to Wordpress - just to be able to "dress it".

Then I decided to convert my favorite wordpress theme to drupal - it is good way, but not the best, i think. I personnaly even would like to buy premium drupal theme - but I coul not find anything!

When google packed by "premium wordpress themes", I found only three (!!!) companies which sold premium magasine drupal template - and all of them are boring... Then, the price is high - an average wordpress theme cost 50$, when drupal`s cost 150... Even designing is TOO expensive - the average price for custom drupal design is 1000$, when most wordpress custom design cost 250.

I think the problem lyes in the fact that drupal uses good company with big budjet... when wordpress uses ordinary people. So it is more profitable for drupal designers to work with such clients than with ordinary bloggers.

I hope that situation will changed... but today i googles for "drupal designer" and did not find nothing interesting again.

(Sorry my english please, i`m not an english speaking person)