web design

The theming firehose (NB for designers & front-end developers new to Drupal)

Drupal markup in a Wordle

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.

Make friends with Firebug.

But wait, can't this situation be changed?

Well, kind of. You can intervene in the mark-up. You can write your own page templates. Your own fields templates. Your own views templates. Your own search templates. Your own node templates. Your own comment templates. But be warned: You're going to be working against a ton of mark-up. And you'll need to know some PHP to add your own variables — mighty powerful and nifty, but your Dreamweaver chops aren't going to help much.

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.

Is the site logo content?

A brief exchange on Twitter with Jen Simmons (@jensimmons) and Morten Heide (@mortendk) about how to best incorporate a site logo into a Drupal theme got me cogitating on this question. Jen tweeted:

...What should go is the habit of hardcoding content into the theme. #separationplease #drupalwtf


"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.

My DrupalCon San Fransciso session: Grok Drupal (7) Theming

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

Then, in 2005, came the PHPTemplate theme engine, thanks to Adrian Rossouw (now with Development Seed), and the heavens opened up.

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.

Learning Drupal Theming in 2010

My session proposed for DrupalCon SF on Drupal theming basics brings a comprehensive look at the Drupal theming system and how the front-end developer new to Drupal can take charge of the output by taking advantage of what Drupal gives you.

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.

Web designers and developers, take the A List Apart survey

A List Apart Survey

The more the merrier (or at least more accurate). Take a few moments to fill out the A List Apart Survey. This isn't just for designers.

Drupal 7 freeze means time for a new tag: #D7DX

Yeah? Maybe?

[update: maybe not. see comments.]

#D7UX [Tweeted] is about Drupal 7 user experience work.

#D7CX [Tweeted] is about upgrading Drupal contrib modules to stable Drupal 7 releases when Drupal 7 itself is released. Over 100 contributed projects now bear this commitment, which is just awesome!

To me, that leaves #D7DX – a focused effort to get some rockin' Drupal 7 design themes going.

Yes, we have #D4D. And beautiful Drupal 7 themes are part of #D4D. But #D4D is also about Design 4 Drupal events, broader #d4d efforts on Drupal.org, and other design efforts that are happening. But why not a more focused tag, not on making Drupal pretty in general, not on improving the designer's experience in Drupal, but focused just on creating beautiful, semantic, exciting, eye candilicious themes for Drupal 7? For core themes, yes, but also for contrib. All ready and stable by Drupal 7 official release. Now is the time!

I'm writing to myself, here, since for someone who's been working with and designing for Drupal since 2004, I'm very late to the contributed theme party. That has to change.

At any rate, it's an occasion to finally get this blog here out of the Minelli realm. That's a long overdue effort. All I need is a little free time.


Tweet Tweet!

A cautionary tale regarding theme download sites

Via GigaOM:

Back in November, we looked at WordPress themes being distributed by third parties who’d embedded hidden code to allow the insertion of arbitrary content. Now a rash of sites are reporting that their blogs have been subverted....

...There are lots of reasons a hacker may want to inject code into a page:

  • To infect visitors by exploiting a browser vulnerability
  • To place ads they can then get revenue from
  • To embed links to blogs they own, improving their page rank
  • To entice people to click on links that lead them elsewhere

The clever thing about the WordPress hack was that it would check for code to insert into a page each time it was loaded, but if none was available, it would just sit there quietly.

It's all too easy to compromise a website's security via the theming layer. Malice is just one possibility. There are also hacks and vulnerable code gimmicks pursued amateur theme developers who just don't know better. It's not just a Wordpress thing -- it's all websites, whether built on open source or proprietary platforms (though not static html sites, which presumably are as safe as their servers).

In this context, the question for the website owner is whether you want to buy a theme (or download a free one) from an un-vetted vendor. Sure, if you are an adept coder, and/or know the proper API calls to protect your site from things like XSS, you can just clean that up and enjoy the design that attracted you in the first place. But if you don't know those vulnerabilities, you could be opening your site up to ill-will or novice mistakes. Caveat emptor. Don't end up like Deep Jive. Ouch.

Firefox 3 making online life much nicer

Today I downloaded and installed Firefox 3 Beta 4. I could not do it before, but now that the Web Developer tools are updated and Firebug has a 1.1 beta that works in FF3, that's enough for me.

I don't know about you, but on both Macs I use regularly, Firefox 2 was crashing all the time. Last night, while writing a blog post for BlogHer, my browser crashed at least a dozen times. On my Mac Pro, Firefox completely melted down -- twice -- requiring complete rebuild from the start, manually adding one plug-in at a time. But I had to stick it out because I need those developer tools. I cannot imagine working without Firebug.

The new UI is clean, and seems to take up a bit less space. And so far FF3 is fast. Me likes.

An Apple Store a day keeps the dreadful designs at bay

So we learn from Secret Notes:

Apple's stylish stores and computers, all of which feature unrestricted Internet access, have become such the hang-out and gathering place for MySpace junkies that the powers that be have elected to block the popular social networking site from its systems.

By the close of business Thursday, most Apple retail stores will have implemented the block, designed to reduce the level of loitering at the stores.

More likely Apple's design aesthetic just cannot brook dreadful MySpace page designs appearing within their bricks and mortar.

The horror! The horror!

OSCMS theming presentation: request for input

I've posted a request for input from those attending the OSCMS Summit regarding the theming session. If you're attending, please respond there. Or here, if it's convenient. We want the session to address your concerns and interests, and your help is requested.

CSS reboot of pingVision

The design of the pingVision site was driving me crazy.

pingVision, the old view

It really wasn't supposed to be the actual site design, but rather a temp theme to be cleaned up and spiffed up a bit. 18 or 20 months later (I actually don't know exactly how much later) I finally got around to replacing it.

pingVision, the new view

It's certainly different. Cleaner. Simpler. Too simple?

I'd started on this new design several months ago, but left the theme half-done in order to focus on client work. Finally I just had to spend a weekend tinkering with it to get it live on the site.

This really was more of a starting over from scratch on the whole template, rather than just a CSS reboot. There might be some bugs in it -- I have yet to see it in IE7, and IE6 worked yesterday, but I made some changes since -- but there it is, in an unofficial live beta. Still to do (aside from debugging): update it and the site to Drupal 5, and update some of our main pages.

So what do you think?

It doesn't really seem right to add our own website design to our own portfolio so this is probably the only place I'll post this.



Get occasional email updates on what I'm doing (and not blogging about).

Powered by MailChimp

Subscribe to web design