Graycor: Drupal Theming in the Works

Avoid using tpl.php files where ever possible.

To avoid using a tpl file for every content type or layout, we planned strategically before building out the Drupal site. Actually let me step back a bit and explain what "strategically" means. Before we build out a Drupal site at Palantir, we generate a Design Implementation document (which in this case was a set of designs scribbled on, in most other cases a PDF with comments) and then there's the Data Model. The Data Model is the key to a successful site and its what makes theming sustainable.

The Data Model is generated in excel, with many worksheets inside of it listing all elements of the site, thus becoming a set of instructions for someone to build out the Drupal site. It lists every field, its options, its Drupal display settings, and its CSS display settings among other things. This document has to be so detailed that we can give it to anyone in the office (who knows Drupal) to build. It even includes help instructions, because seriously who wants to be adding those in right before site launch.

By walking through the Data Model, field by field, you start to architect a site that can reuse CCK fields on multiple content types. We also standardize our field naming convention at this point. Now remember...we haven't even installed Drupal, this is all Excel. The other benefit of reusing CCK fields is to increase the speed at which you can create Views. When you have 5 different Views that all have teaser copy and thumbnails, you WANT to clone as much as you can.

When we're architecting out the site in the Data Model document we're also thinking about how we're going to build it out with CSS, and how specifically we can avoid destroying the $content variable in the node.tpl.php file. For Graycor we only needed 1 node.tpl.php file - for individual projects because of the required formatting for taxonomy. We thought long and hard about how we could use the display settings through CCK and how we could position items with the code we knew Drupal would spit back out at us. This process took approximately 20 hours. Which leads me into our next goal...

Create default CSS stylings and reuse as much as possible, "Theme" don't "Skin"

The first step to theming (in my book anyway) is to understand your fields, how Drupal's gunna spit them out and how you're gunna grab onto them and reuse them. Ok thats more like 4 steps, but still it is one process. So how do you do this? Its actually easy, just tedious. If you're gunna create a date field...you name it something predictable, like "date". This means that Drupal labels it "field_date", and your div class around that date field will be something like "field-field-date". If you need to add another date field with different field requirements, you name it "date_news" or something related to the content type. Or how about an even better example...lead copy. Lead copy is a field that we always use as the "teaser" or the shortened and editorially controlled copy that is displayed on a View in place of the body. We know that on our site 5 different content types will be rolled up into a view and will have a thumbnail. We also know that all 5 content types have lead copy. That means if we use the same field for each (if the requirements are the same of course), then we get a class of "view-data-field-lead-value" on our wrapping div for that item in the View. Thus letting us style defaults for a View that uses List style, shows a thumbnail, title and teaser copy. Here's an example: http://graycor.com/projects/results/49.

Of course at a certain point you are going to have to get more specific with your CSS, but our goal was to avoid the amount of times we needed to restyle new content in the site. We wanted the site to be flexible enough that if the client wanted to add a brand new view of any style type (table, full node, etc.) it would be styled already for them.

Leverage the Drupal admin everywhere we could.

Leveraging the Drupal admin? What does that mean? Well it means make as many things configurable from the admin as you can. This means if you can avoid using the views theme wizard (yes this is a Drupal 5 site), then you can rearrange your fields on the view all you want, never having to open a tpl file. We also try to use CCK labels where ever possible. For instance on the project pages, we use the CCK label of "Project Scope" and the "Client" label as well. Our rule of thumb is that if you can use a CCK label you should, because if you don't, guess what you might need a node.tpl.php file, and like I said earlier,...we're trying to avoid those. You don't want the client to need FTP to edit their site. Drupal is a CMS, use its admin, and let the client use it too.

The other option of course is to use preprocess functions, which Larry Garfield so graciously back ported to D5 for us: http://www.garfieldtech.com/blog/preprocess-drupal-5. I'll let Larry explain this one in detail because I don't think I could do it justice. But for those who are less of a programmer, like myself, it basically helps you do thinks before the page is processed, like wrap a link cck field around an image field :). Quite handy, and helps with that no tpl.php thing.

The last and final piece to pull all 3 goals together is to build an Interactive Prototype. For Palantir this means build your entire site map out - based on the Data Model, build the content types, the greeked content, the views, everything. And use the Zen theme. Then you can start CSS, but not until this point. You can't build CSS defaults without the entire site built out in Drupal.

So why was Graycor so successful from a theming perspective? Because we were testing functionality during a Prototype stage that we often wait until Beta to do. Beta became more about content review and final tweaks and less about custom functionality and Views setup. This was our goal, and we achieved it. And Graycor is a rock solid site ;)

Oh yeah and did I mention we live, eat, breathe, and die by Zen, use it, be it. Zen.