Recently I was digging into the documentation on Drupal.org. 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 Drupal.org 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.