Seeing What Has Been Done in Drupal Theming

Recently I was digging into the documentation on I was looking for information about changes that have been made to the theming layer in Drupal 8. I was looking for resources I could provide you, my reader. I wanted to show you the reasons why the code was the way it was in Drupal 8. I've been to conference presentations on the subject; I assumed the information was there. But the documentation I found was inadequate. (More later about how we can fix this.)
I'm not dismayed. In fact it feels really familiar. From chaos, clarity will emerge. There are others, like myself, who cannot leave information cluttered. As with previous versions of Drupal, the documentation will eventually be produced. New handbook pages will appear, and we will, as a community, refactor this information until it's acceptable.
Before I continue I want to take a step back and review how we got here. I'll start with a heads-up. I'm going to write about theming lite. Think of it as redecorating an existing framework, but not designing an experience from the ground up. I learned early that it was easier and cheaper to work with Drupal instead of fighting it. Perhaps my sites all looked similar, and perhaps they weren't the most elegant. But they were functional. They fit the budgets of the clients I was working with. I have done a lot of theming, but I am not a front end developer. I use base themes and helper modules when I can; preferring to find existing solutions instead of inventing my own.
Over the years I have gone through phases in how I approach theming in Drupal. In the beginning, I restyled Drupal Core. I built simple sites, and then created a style sheet which redecorated the rendered page with CSS. Initially I created templates (lots of templates) to adjust the layout of my pages. I was comfortable with code, and theming in this way met my needs. Front End Drupal used these techniques, and you can still apply the concepts I wrote about in this book, even though the code is specific to Drupal 6.
My next big leap was learning Panels for layout. I even ended up contributing a chapter to Earl "merlinofchaos" Miles and Lynette "esmerel" Miles's book on Panels. This introduced me, and by extension my students, to a more "accessible" form of theming where there was much less reliance on code, and a greater exposure to an increasingly complex point-and-click user interface. (I was never in the Context camp, although we do use it on Drupalize.Me.) As themers we were encouraged to write custom plugins, but I typically found myself just teaching site builders the basics of how to click together a custom layout.
As Panels matured, we saw the rise of base themes and helper modules. Zen, originally authored by our own Jeff Robbins, had been around for quite some time...indeed long enough that it had been re-written by our own John Albin Wilkins. Zen is still one of my all-time favorite base themes. Its documentation is exquisite. Toward the end of Drupal 6 and into the beginning of Drupal 7, we began to see the rise of base themes that incorporated "helper modules" for point-and-click layout configuration: Omega (version 3.x) and Fusion both had their own (Omega Tools, Delta, Fusion Accelerator, and Skinr). These base themes essentially were writing their own layout engine on top of all the other pieces. It added complexity, but also simplified the experience for intermediate themers, as they could learn a single philosophy instead of having to find, install, and learn what felt like an outrageous number of modules.
Somewhere in here responsive happened. At first we simply layered a responsive style sheet on top of what was already in place. More than a few of us wrote articles about how we could collapse an existing Drupal site in no more than a few hundred lines of CSS. We thought about "breaking" our design into smaller chunks which flowed together. Then designers asked us to flip this model and start from the content out (Mark Boulton); or from mobile up (Andy Clarke). Drupal base themes struggled to keep up as best practices seemed to change constantly. Drupal Core became increasingly frustrating to work with as there were so many extra libraries that needed to be added to make it feel like a modern front end developer's toolkit.
As novice themers became more frustrated trying to decide which base theme to pick, we were given an interesting twist to deal with. Where the base themes had been diverging, suddenly we saw them coming back together with a set of standardized tools in the project Magic. On this list of committers for this project, we see developers from the base themes Zen and Omega.
This collaboration in the contributed module space allows developers to talk about what they have in common. When developers can find the overlap in their toolsets, it becomes easier to determine what should be incorporated into Drupal Core. The conversations aren't always easy. You can read a list of the changes which affect themers that have landed in Drupal Core. The change sets all link back to the original issues where the discussions took place.
This cycle of tool development feels familiar to me in a non-coding way. Imagine, if you will, tucking your hands into an elastic band. Your immediate impulse is to stretch your fingers apart—to test the limits of the elastic band. With each version of Drupal we spread ourselves apart and stretch the limits of Drupal. We stretch and test in the contributed module space. Sometimes, when enough of us stretch in the same direction, we snap back together in a new version of Drupal with a new set of common tools before we start to stretch and grow apart again.
I find it reassuring to look back and remind myself that there has been confusion before. Chaos doesn't need to be a source of fear, uncertainty, and doubt. It's a delicious playground for those of us who love to organize information. The pieces are in place, we have the context of where we've been. Next week, together, let's dive into this chaos and start finding the clarity which the code already provides. But instead of stopping there, let's also investigate how we can better share this clarity with others.
Related Topics: 


I didn't know about Magic! You just made my day-week or month ;)

Thank you Emma!

Yay!! There are so many great little modules out there. Another fun place to look for up-and-coming modules is this site: (PS I'm absolving myself of all blame if you lose entirely too much time on that site. ;) )

The committers to magic also include the maintainers of Aurora, which is an amazing base theme with some great sass tools built into it. It's really changed how I approach responsive theming and the documentation for it is out of this world. If you've not tried it, I can't suggest it strongly enough. (It also integrates really nicely with theme provided panels layouts) Give it a spin!


I really enjoyed this article as it summarizes things the way I usually talk to clients and fellow Drupal builders and developers about Drupal theming.

Working with many themes, both as base themes or custom or modified, and most recently with Zen and Omega, I've come to conclusion that theming and Drupal are and should be two things. Actually, theming should be as independent from Drupal as possible leaving all hooks and code to Drupal modules not themes. And themes should be all about CSS that fits into well thought of HTML structure.

That aligns perfectly with Drupal 8 and Twig where that separation seems to be brought to formal divorce between presentation and logic.

I am eager to see what your next piece will bring as it does represent an effort toward quality work on Drupal and theming.

And final clarification of the really murky waters of the best theming practice in Drupal.

P.S. I am still swinging between concepts brought in by Zen, Omega 4, Adaptive theme, Aurora, Basic, Boilerplate, Bootstrap, Mothership and I am locked by vast sea of options brought to table by them as what is the best way to approach the problem. Once the metrics is established some weight can be assigned to each project on each metrics axis and see how they stack against each other in context of the particular project.

Add new comment