header photo

via positiva

On the complexity of Drupal theming

Those who know me know that I am official consumer of the kool-aid when it comes to Drupal. It is, after all, the best CMS on the market. There have been quite a few threads on the Drupal site, though, discussing the dearth of good themes available for folks who want a swanky looking site. Those who dive in and try to build their own without considerable experience tend to run screaming. Or, if they persevere, end up with a slightly modified version of one of the core themes like Grey_Box. (For this blog, I just grabbed one of the more attractive themes and haven't bothered customizing it. Rolling my own theme is on the to-do list, but what a loooong list it is...) Anyhow, I spent some time looking around at some of the highly visible "showcase" themes for blogging software like WordPress and Movable Type.

What I started to notice was a trend: the themes that got lots of attention, the ones that rise above the crowd, fall into two rough categories. Either they're highly customized for a particular approach (a photo-blog organized by photographer, for example), and thus unsuitable for general use, or they focus on flexibility and compatability with third-party plugins. In the world of Movable Type and WordPress, it's a foregone conclusion that connecting your blog to your de.licio.us favorites or adding a 'quote of the day' in the sidebar will involve wading deep into templating languages and perhaps Perl or PHP.

One of the snappier WordPress themes, K2, boasts features like "compatability with multiple authors" and "Showing the latest comments." A lot of work has gone into making K2 flexible enough to deal with more than one or two configuration scenerios, and the work shows.

What really struck me, though, was that any Drupal theme released without that sort of flexibility would be sent back to the drawing board as broken. New modules are released almost daily, shoving new content types and new presentation paradigms and new tools and options into the Drupal framework. The Drupal themes one can download from the main site take them in stride thanks to the tremendously flexible PHPTemplate system that (almost) everyone now uses.

I've thrown together quickie themes for Drupal that make all sorts of assumptions (we'll never had sidebars, we don't need to display comments, only Module X and Module Y will ever be installed...) and it's as easy as any other system. Easier, in some cases. In about twenty minutes , I whipped up a very rough 'compatability theme' that lets a Drupal site use CSS skins originally designed for Movable Type blogs. But making a theme that's visually stunning, cleanly designed, AND flexible enough to handle anything J. Random User installs into their Drupal build can be a pretty daunting task.

I suppose this post is both a defense of Drupal's relative deart of themes and a challenge. Should we simply resign ourselves to the fact that Drupal installs will either use simple CSS skins, or elaborate site-specific layouts? How can we, the Drupal die-hards, figure out ways to make the 'middle ground' more approachable?

Intersting post Jeff. I have been thinking about similar..

You maybe right, but, I tend to disagree with you're reasoning...the same could be said for modules, but, judging by the amount of modules contributed..it doesn't seem to be the case.

Modules start life as a 100% site-specific "template" of functionality.

Similarly, some would argue that Drupal (php) snippets start life as 100% site-specific entities, yet since I started the Sliced Bread PHP Snippets handbook section....it has exploded.

I would reason that there perhaps isn't a culture of sharing themes within the community. I maybe wrong...but, I'm willing to chance my arm that if the community was "nudged" a little in the right direction...we would see more people share their theming gems.

I have given this a good bit of thought..and my guess is that nudging the culture of sharing themes may work, but, I think it might be wiser if we "modularise" theme contributions.

IMHO that will be more succesfull at attracting contributions and I think, long term, a theme snippets respository will be more valuable than just increasing entries in the themes folder.

What I mean is that approaching theming with Drupal is not comparable to ZEN-Garden, for example...which is pretty much a 1-page-skinfest. There's a lot more to it than that...similarly, porting wordpress or php-nuke themes isn't really of much value. Drupallers are just going to strip them apart anyway.

Instead of more themes..I'd like to see the emergence of a CSS & TPL snippets repository, where the contributions are more modular. i.e. Template (TPL.PHP) snippets with accompanying CSS style snippets to make your blogs, comments, blocks, menus, footer etc. etc. look a certain way.

There's no harm in having more "shells" to get people started but, the snippets approach, to me, would be more powerful and practical than more "complete" themes.

I've already started it - as an illustrative example, if you click through to the PHP TEMPLATE section on the handbook...select "Example - Theming the user profile pages" and then select "User profile page Snippets".

If you consider that pattern replicated for blogs, comments, pages, admin pages, blocks etc. it enables Drupallers to not only contribute easily (as was proven with the Sliced Bread PHP Snippets section) but empower their theming skills.

Anyway..that's my take on why there are very few contributed themes with Drupal and instead of "nudging" the culture of contributing back more themes or running competitions - as was suggested, I think a more modular approach to theming..where Drupallers can copy and paste tpl.php snippets or straightforward CSS style snippets would be more valuable.

Dub

Thread on Drupal.org

Hi Jeff,

I've started a new discussion on Drupal.orgs forum outlining my ideas..
http://drupal.org/node/38148

Appreciate it if you could toss in your two cents..

Dub

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <img> <i> <b> <strike> <h3> <h4>
  • Lines and paragraphs break automatically.
  • You may use [inline:xx] tags to display uploaded files or images inline.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Twitter-style @usersnames are linked to their Twitter account pages.
  • Twitter-style #hashtags are linked to search.twitter.com.

More information about formatting options

Miniblog

  • Totally got the third item in that list from @blakehall btw. He's the clever one! 1 hour ago
  • There are two hard problems in CompSci: optimal cache invalidation, naming things, and off-by-one errors. 1 hour ago
  • OH: "Well, the Title title can just be the title, but reign_title can't be the reign title, or the title title." 4 hours ago
  • Know Drupal? Dig wrestling? Looks like the WWE is hiring... http://j.mp/bSu4pB 2 days ago
  • I want to be the Malcolm Gladwell of Drupal APIs. My breakout book will be named 'Clear Cache.' 4 days ago

SXSW Interactive 2011!