theming

It was 2001 when I first started blogging. It would be a few years before I heard the word "blog", so maybe my early endeavor in online journaling wouldn't count for purists, but I was journaling online. This was a rather introspective period in my life and I felt compelled to my thoughts and experiences in this worldwide web I'd been playing with for several years. So I hand-coded a site, a static HTML affair that I had to update completely every time I posted an update. (I didn't really care for the limitations of the various services out there.) Over the next year and a half, the site grew in size, making my deployments more complicated. The blog also became collectively more and more emotionally raw, until one day, in a fit of mortified embarrassment and disgust, I deleted the whole thing and didn't look back. So yes, I started blogging eleven years ago, but I haven't been blogging for eleven years.

In 2004 I started doing some ranty blogging with a political slant, and I've continued that over the years, pseudonymously, first on Blogger, then on a Drupal site I built myself (my first, actually). Chalk it up to political cynicism fatigue that I have scarcely looked at that site in quite some time. It's hard for me to allow myself to get worked up over political issues, especially when our politics are so broken. It's an emotional space I don't care for. It drains me. I remain engaged politically, but my engagement no longer includes political blogging. That may change in the future. Who knows?

This blog I started in October 2005 to blog about stuff that interested me. Those were interesting times in 2005. I was still absorbing the profound changes technology was effecting on our culture and in our daily lives. I'm still absorbing it, actually.

So, in technical terms, my online life has shifted from a self-built flat html site to a saas blog to some self-built blogs, commercial sites, and communities.

Over the last couple of years, the foci of my sharing compulsion have gradually shifted towards Twitter, Google+, Facebook, Tumblr, and the like. The interconnectedness of these networks is what appeals. It's what works better now for quick sharing, sad to say, and it's what I feel is more indicative of trends in the future.

So why spend time going back and updating this blog? It's a silo, for the most part. A year or so ago I tried an experiment ameliorating that feeling by replacing the Drupal comments system with Disqus comments, and I think that has helped make this feel less like a silo, more connected. People who have never seen this blog can follow a link and find that they are already logged in to share a thought in the comments. Others can log in using any of a number of existing accounts elsewhere. Identity management wins (albeit in the proprietary realm).

This blog is also my home, in a sense. I feel a responsibility to maintain its upkeep. And part of that is progressing with the rest of the Drupal community. I share in this fabulous commons, and the drop is always moving. I must keep moving, too, even for this oft-quiescent blog.

You theme with the mark-up you have, not the mark-up you'd like to have.

That's the essential truth that designers and front-end developers new to Drupal need to understand. You don't get to construct your pages from scratch, building out essentials, never a wasted div, never an extraneous class. No, you have to flip the entire process around. With Drupal you're getting markup shot at you from a firehose, and as a themer you need to sop it all up and make it pretty. Don't spill a drop.

What this means is that, by default, you're spending a lot of time debugging the theme you're building so that it handles all the different configurations, content types, page structures, etc. that the Drupal site is throwing at you.

You have to be braced for it. It can be overwhelming. You can feel like you're drowning. Don't worry. You'll get used to it after a few months. Mostly.

You see, Drupal aims to be flexible, and it does that by throwing a zillion divs, spans and classes into the output. That means if you're not expert at CSS, you're going to be lost adrift in a sea of markup, and if you are expert at CSS, you have to learn how to see through the clutter — because when you have four or five nested divs to contain one single element, it's not necessarily obvious which one to target with your CSS. Especially if there's some nefarious Drupal core CSS already at work.

There are endeavors to make Drupal mark-up better, including in the HTML5 Initiative. But that's a slow process, and it sometimes meets heavy resistance.

Meanwhile, to get sites themed now, you may have to change how you work. Change how you view the web “page”. Get used to being the html sponge, absorbing and directing the firehose, using only the drops you want and letting the rest by without touching a thing. Let go of the idea that you're building from scratch, and get used to the mindset of diagnosing what's already there.

That's the price of power. Drupal is incredibly powerful. You need to flex your theming muscles to match what Drupal throws at you. Work through the complexity. Trust in Firebug. And don't despair. In the end, the resulting webapp is orders of magnitude bigger and badder and more kick-ass than what you could have done on your own, having 100% control but going it alone.

"Content"? Hmmm. This got me pondering: Is a logo "content" per se? My immediate response was in the negative. But upon further consideration, I don't think it's all that clear cut; I'm definitely less certain today than I was yesterday.

This post is a bit of thinking out loud on this question. Comments welcome! (But no need to shout #wtf, okay?)

Content or architecture

To me, "content" in a Drupal site is the content, as in nodes, comments, image uploads, embeds, etc. The content is the information. Come back to an article on kitten care a year from now and the content will be the same (or at least it should be).

The logo, on the other hand, is a graphic component of the user interface as well as the branding. The logo is the visual representation of the site identity. It may change and evolve, as logos do, as user interfaces do.

But functionally the logo in the web application is really a part of the site's architecture. The logo is "home." Redesign the site, revamp the logo, change its colors, replace it altogether — it is still "home" in terms of the functionality of the application. In that sense, it is fundamental architecture.

When planning, designing and developing a custom website, the theme is custom, a part of the entire design that includes architecture. (At least, this is the assumption I'm working from.) One typically does not move a logo around on a page willy nilly. One typically does not swap out the logo for another — not unless you're also changing the theme as well, as part of an entire redesign. The logo is a part of the whole user interface, the whole user experience, the whole compositional balance of the page. Conceptually it's hard for me to split out the logo as represented on the page itself as somehow apart. Logos have their own separate life, yes, but in a user interface context matters. One might even argue that the entire user interface is all a part of the branding, with the logo just playing one part. One might....

One of the advantages of a Drupal site is that a site administrator can actually manipulate the site architecture without touching code. This helps site building happen much quicker than it would otherwise. This admin control over architecture also can be handy for site owners, even if used only once or twice in a year. And it constitutes configuration stored in the database.

But does that make architecture "content"?

Drupal is very good at blurring the lines between functionality and presentation because of this paradigm. In puritanical (small "p") terms, it's undesirable, this blurring the lines. But in terms of usability and convenience for site owners, it ends up being empowering. Site menus can be modified, added to, deleted from. Blocks can be repositioned. The user interface, in other words, ends up being extremely malleable and subject to the whims of any user with the appropriate administrative permissions.

But is it content? I guess it depends upon what you mean by content. In terms of interaction design, I tend to view the site logo as a component of the entire user interface design, as part of the architecture in terms of functionality.

The Way Drupal Theming Was

When I started Drupal theming in 2004, it was all a bit overwhelming. Back then, the core theme engine was something called Xtemplate, and it gave the impression to the n00b themer of being a great big mess. When you looked at the page template, it was one big blob of markup and logic, and it was very hard to figure out to change just about anything. What's more, it seemed to be very brittle: change something and you got the white screen of death.

And thus life was for the themer through Drupal 4.5 and the beginnings of 4.6.

New Drupal Theming Power

Suddenly (well, not suddenly, as it took a lot of work) Drupal templating had a structural logic: a nested system that simplified the clutter, gave us defined variables to work with, and provided the basis for extending the system. This was really really cool — so cool that it immediately became the theme engine of choise, and, with Drupal 4.7, it became the theme engine for Drupal core.

I was so excited about it, I did my first Drupal conference presentation on it, at OSCMS 2007 at the Yahoo! campus in Sunnyvale. (It was part of a larger topic of overriding display upon which I collaborated with Greg Knaddison and Ezra Barnett Gildesgame, now of Growing Venture Solutions. The PDF of my slides are available here, though they're pretty outdated now.)

Since then the Drupal theming system has evolved and improved. There are a lot of nifty techniques, tricks, best practices that are available to the themer. What's essential is having a good understanding of the underlying architecture, because that's how you can figure out where to look, how to go about making the changes you want to make the theme yours.

No PHP knowledge is required ... beyond knowing not to muck with what's between the <?PHP ... ?> tags. Of course, knowing some PHP can help. But you can also pick up the basics as you go, if you want to delve into the coded bits.

You won't come out an expert — that would be a ridiculous promise — but you will come out able to start rocking your own themes. You will have a solid understanding how the Drupal theme is structured, how the various templates work together, how to define regions, how to add your own targeted CSS files and scripts, use of subthemes, some good base themes to work from, how to do custom overrides of obscure, quirky or persnickety output using preprocess ... and you'll grok theming in such a way that even if you don't know how to do something, you'll know how to go about figuring it out, where to look, what to change, etc.

And because we're about to enter the age of Drupal 7, this presentation will be about these things for Drupal 7 (with some notes on how things have changed from Drupal 6). So this session could also be of interest to the experienced Drupal themer who hasn't had a chance to delve much into Drupal 7 yet.