Category: Internet / WebTags: DrupalDesign

Building a Drupal Web Site can be a very scary task to both beginner and experienced web designers. I have been building and theming Drupal web sites for about 2 years now and during this time I have developed my skills and picked up a few things that I would like to share.

It should also be noted, that as with any website, good design is not just entirely graphics and typography and stuff. A lot off good design is a well-planned out site with useful features, lots of content in the right places and things of this nature.

You still have to be a decent designer

If you want your site to look good you still have to be or have a decent designer handling it. That's just the way it is. Although Drupal has many exciting and cutting-edge features, these types of things do not make your site stand out as unique and powerful on their own. They need that special touch of an experienced designer to give it the direction and vision that it deserves.

Try to follow the flow of Drupal

When I first started with Drupal I didn't quite fully understand how everything really worked so I would try to force my way around theming. Rather than utilizing something as simple as comments I would try to build my own type of comments that were more "customized" and more precise to what I was looking for. As I soon realized, this became a huge problem and I started running into bugs and theme problems.

It is a much wiser move to try to understand how everything is working together and make sense of it before trying to force your own way on things. All the unique elements of Drupal offer their own set of strengths and weaknesses. Sometimes it may make sense for one and other times it may make sense for another. With a more complete understanding of all the parts of Drupal it really does help A LOT in theming and site building.

I have assembled a basic run down of some things that I usually think about when I begin theming a Drupal site. Most designers may not think this kind of thing is important and ironically this is also the reason why most Drupal sites lack the professional look that they deserve.

A quick run-down of things to consider when planning a Drupal site
User Pages

It is important to understand that all User pages have their own types of attributes. User pages are NOT nodes and do not allow for a lot of the things that nodes do allow for. If you want to have comments on your users pages you can't. You can't use CCK on your user pages either. If you want to have profiles for your users you may be limited by the default "profile" module. In fact, the default profile module can easily be replaced by CCK. For all of my sites I don't even use the user page as the user's page really. I mainly use the user page as a way to keep account information and stuff, but it makes much more sense to me to have an actual node as a user's profile. This way it is much more community oriented and allows for a lot more. As a node you can now comment on user pages, save them to favorites, search through the content on them, have the same moderation features nodes have and soooo much more. To me, this is the only way to go on a more high-end type site.

Nodes

Nodes are the heart of Drupal. Pretty much any type of content on a web site should be a node. In my opinion, it is usually best to try to keep each type of content constrained to 1 node. That is, try your best not to have 2 or more pieces of content part of one node. For instance, a lot of the time I see people use CCK to attach images to a page node. This may be good in some cases and a quick fix, but it also may not. What if you want somebody to comment on your image? Since it is actually embedded as being part of your page node, it itself is not a node and does not offer any node features. What if you want to allow users to upload images for this particular node, would they be able to? What if you want to allow more than just 1 image per node? What if you want to allow many different types of attachments to this node? These are all questions that I consider and others should consider as well. In most cases I find it much more beneficial long term to allow each piece of content to be its own node type, including images, video and anything else. These items can then be referenced to other nodes using modules such as CCK's NodeReference and other type relationship modules.

It should also be noted that nodes have a huge list of contributed modules that can become super helpful for the organization, management and usability of nodes.

As I touched on earlier, nodes also allow for commenting so it is a good idea to try to keep anything that you want commented as a node.

Taxonomy

Taxonomy is another part of Drupal which should also be understood in order to move a site to the next level. Taxonomy has a few unique features that only apply to it.

The first thing to note is that each taxonomy is basically a category that allows for the categorization of nodes. A "vocabulary" can be created that will hold different options for the user to select when creating a certain type of node. For example if you wanted to select the color for your product node you would create a vocabulary called "color" and assign it to the node type "product". You would then create the options or "terms" for this vocabulary. Such terms would include red, blue, yellow, green, etc. When a user went to create a new node they would now be presented with a Color dropdown that allowed them to select the desired color.

Everything that is part of a taxonomy term also has its own page automatically created that now lists every node that is contained in that term. So for example if you had 3 different nodes assigned to the "red" term on the color vocabulary when you go to the page mysite.com/taxonomy/term/1 (where 1 is the Red term ID) you would see 3 nodes that belong to the red term listed from newest to oldest. Mysite.com/taxonomy/term/2 (where 2 is the Blue term ID) would list all the nodes that belong to the 2 term.

Blocks

Blocks are a great way to add all the cool little sidebar stuff that should be shown on either the current page or multiple pages. Blocks usually contain stuff like similar links, people also did this, subscribe to this here, top 5 images, most bookmarked and stuff like that.

When I first started out with Drupal I would try too hard to include my own types of blocks in my custom node-x.tpl files. I would create lots of cool little details about the current node in these files. I started to run into problems, however, when I wanted to quickly move this piece of text somewhere else, or even on another site as a different style. It really is important to try to keep the pieces of your site broken down as much as possible.

Tabs

The tabs are a useful feature that are often overlooked by most newbies to Drupal. These tabs contain both sections and sub-sections for the current page that a user is viewing. For instance when viewing a node the user will be presented with the options for "view", "edit" and whatever else has been added here via modules. These tabs can become super useful and should not be overlooked. A lot of the times certain key features can be lost if tabs are not added to the theme.

CSS is key

Due to the nature of Drupal sites, they are usually very content and text driven. This creates great opportunities for CSS as there are many places to style headings, paragraphs and links.

Make use of the theme() feature

The theme function of Drupal is very cool. It allows any function from a module or core file that uses theme_ in front of it to be over-ridden in your template.php file. So what this means is that you can easily change the way a table, username, breadcrumb, pager or even the way comments appear. It is very handy and should be utilized when necessary. For instance, if I wanted to change the way my items listed with theme('item_list') were themed I would pull open my theme.inc file in the includes folder and search for theme_item_list. In here I would be able to over-ride this function and now add or take away from it.

Views can come in very handy

About a year or 2 ago I used to create custom modules and pages for the sole use of listing nodes of a certain type and of a certain taxonomy. With the release of view.module this is no longer necessary as view does this for you on the fly... and then some! View is very handy for creating lists of nodes with a number of parameters such as comments, node type, number of views, date of creation and so forth. Super awesome and useful!

Nodes have 2 templates, the teaser and the body

I didn't understand this concept for a while so some things were confusing to me. I didn't get why the nodes on my homepage looked different than when I was actually viewing the full node.

Nodes have both a teaser and a body element to them. This can be determined in the $page variable located in the node theme file. So if you were viewing the teaser of a node $page would be set to 0. And if you were viewing the body of a node $page would be set to 1.

So you can do a quick little php conditional on your node.tpl file to theme your teasers different than your nodes:<br>if($page){<br>//theme body<br>}<br>else{<br>//theme teaser<br>}<br>

Use different content types for different types of content and theme them with their own node-type.tpl

If you are going to want different types of contents to look differently then you're going to want to give them their own content type. Each content type can have its own theme file so it makes sense to break up your content types accordingly.

Majority of the work can be done with page.tpl

Page.tpl is roughly about 80-90% of the site. First impressions by users will be made off the page.tpl alone. It is important to focus some effort on the page.tpl. This is where having an experienced designer could really come in handy. I usually like to treat the page.tpl just like I would any other site. I first start out in Photoshop and come up with a layout that fits the goals and intentions of the site. Once I am satisfied with everything I strategically export certain elements from Photoshop and bring them over to CSS and my page.tpl.

Avoid hacking up page.tpl.php - Use modules instead!

I would also like to warn against hacking up the page.tpl file. At times it may become appealing to write a quick if statement to maybe hide a certain part of the page for certain sections. Or it may be appealing to show a registration link for users that haven't registered. While this may be a quick fix and get the job done for the time being, I would advise against it as it will only create more and more problems as you try to keep adding more and more "hacked" features via your page.tpl. The better approach to do this which I now use is writing custom modules for these little features. If you run multiple sites it will also be much more helpful as you can easily use these similar little features between sites.

Over-ride core CSS files if you have to

Core CSS files such as system.css can be over-ridden if necessary. For instance, on my tabs I usually like to theme them differently than the default look so I usually will have my own style.css that cancels out the CSS on system.css. This way I never actually delete the file from core and I still maintain the desired look I want with my tabs.

The default user pages suck

As I hinted at earlier the default user pages are trash. They just are. They are boring and nobody cares about how long you've been a member. They want to see your content and learn about you! As of right now you pretty much will have to do some over-riding of the theme_user_profile to get around this. For more information on this you may want to check out this sweet Drupal article.

Try not to over-complicate things

Sometimes all these different things can get very cumbersome and confusing. Every once in a while you may want to step back and just go with the Drupal flow again. Drupal does have pretty much everything worked out so if you are struggling with something you may not be handling it the way Drupal wants you to. Step back for a little bit and see what other options are available to you. You'll be surprised sometimes to find that what you were looking for was just a click away!

Relax, it's not that bad!

It really isn't. Building and theming a Drupal site shouldn't be too bad with the right people and the right vision. In fact it should be 100% easier than building a site with any other system, including scratch. Drupal is the only way I build sites these days because it is just so powerful and so quick that it's the only thing that makes sense to me. I used to build sites completely from scratch with my own type of CMS and that was just retarded (and not the good kind). Drupal makes you quicker, more stable, more secure and much, much better. Drupal rocks!