When it comes to theming a Drupal site, there are some different approaches available. We'll take a look at one of them which I believe is the easiest for non-programmers, offers reduced maintenance costs and represents an emerging standard which can drive wider adoption of Drupal.
I've encountered two big misunderstandings about Drupal theming. One is that Drupal is particularly hard to theme and requires highly specialist knowledge. The other is that it is inflexible and doesn't allow you to specify the HTML that is being output. Here we'll briefly touch on how a designer with basic templating skills or a front-end coder can precisely control the HTML and content which is output by a Drupal module without requiring the help of a back-end developer. And it's worth bearing in mind that everything in Drupal is a module so this means that you should be able to customise any element of a site using this approach.
One of the hardest tasks with a CMS or any dynamically driven site has often been customising the look and feel to a satisfactory degree. Over the past few years largely in response to this we've seen a lot of efforts to separate the presentation layer in the various web frameworks and Drupal is no different in that respect. In Drupal this is all done within a site's 'theme' and Drupal offers us two methods for changing how our site looks. These are theme functions and template files and they are used in conjunction. I'm going to propose that almost all customisation is done using template files.
Drupal has historically had a lot of developers as users and so the level of php proficency has been relatively high for a php CMS system. Older versions used to largely rely on php functions arranged as a kind of library of display helpers in the theme. This is not dissimilar to other frameworks and is workable if you have a developer on call. Working this way can be slightly easier and more familiar to developers and prior to Drupal 6, this had much better performance characteristics. However, you end up with a large file containing many php functions which is very opaque and where a single typo will bring a site down. If you are not a confident coder, you really don't want to touch this on an important production site.
The other approach is to use template files - these are php-based but not dissimilar to working with Smarty for example. Since Drupal 6, there has been an effort to minimise the function-based approach and to do as much as possible just using template files. This puts control in the hands of designers and front-end developers and allows day-to-day changes without needing to involve a back-end developer. There is no longer any performance penalty (as templates in use are cached in a theme registry). Most useful content can be changed this way. (It looks like Drupal 7 will take this approach further and allow any output to be modified easily without resorting to code.)
Old habits die hard and you will find that some contributed modules don't yet offer the file-based theming I'm going to show here. However, many more recent ones do. For those that don't, a developer can make any theme functions available via template files in your theme. So if you work with a developer who tells you to 'just start overriding themeable functions', you can instead ask them to map them to template files for you (hook_theme() now makes this simpler). If you identify all the parts you want to change they can do this in one shot.
So we'll take a quick look at a contributed module. The Gigulate module displays gigs and aggregated news using the Gigulate.com API. We'll mainly focus on the upcoming gigs block it provides. But the principle is the same across the board in Drupal theming and you should be able to apply this to most elements of the page. Here it is in a brand new install using all the defaults out of the box. You can see this is a default list style and notice that the dates are in the default US format of this site.
We'll look at how to adapt this to fit in with other sites. There are a couple of ways to approach this but by far the easiest is to use the theme developer which is part of a module called devel. Once you have devel installed, you should enable the devel block (and limit access). This block has a number of links including one to enable and disable the theme developer. (You'll find you want to disable it when not in use as it slows page loads.) The theme developer is a little like the outline tool in the firefox developer toolbar - you hover over page elements and they are outlined with information about them. With theme developer, you click on an element and an info box will give you detailed information about how that is rendered.
Noiseloop.com is a music news aggregator site and has just enabled this module. This site uses a very popular theme - Morning After - which has had some light restyling. The gigs block is currently using the default templates that come with the module just as in the previous site I showed you. We can see that the theme's CSS is already taking care of this block to a large degree and that dates are now formatted to the site's default. But we might decide to change the layout, content or maybe the underlying HTML for SEO purposes. We'll look at where we'd need to go to change the structure of this area. Enabling the theme developer module causes a 'Themer info' checkbox to appear at the bottom of the screen. Checking that allows us to examine any element of the page and see what makes it tick.
When we click on one of the gig items, the themer information box shows us which template file is used to create the output. We can see that it's a file called gigulate-block-gigs-item.tpl.php We just need to create a file with the same name and place it in our theme to override this. The usual way to do this is to locate this file in the module and copy it. Theme developer makes this pretty easy by showing us the full path to this file below (File used:). But it even goes a step further - that's a clickable link which takes us to...
...this - theme developer even provides us with formatted source code for our template file. We can see that this is a typical template file which mixes php and html. There is a large comments block explaining what variables are available to the designer. And the fragment at the bottom is responsible for the gig item we highlighted. This file's comments show that it has a variable called $item which contains extensive content in various fields. Our fragment makes use of the artist name, URL, venue name and date. So we can see that we can easily change the h6 tag that the title is in or add a class to it. Or we could add an artist picture into the gig listing and so on. (The template even has latitude and longitude so that we could possibly add a map here.)
And here's an example of a customised template. We can see that this is in the house style of the site and there are also 'buy tickets' buttons.
The Gigulate module also provides a related news block with aggregated news from various sites. Here we can see that it's again been themed to be consistent with the rest of this site and fits in with their own editorial content.
As I said, this approach can be used generally and isn't limited to contributed modules. Here, we are examining the site search box.
And again we see a large comment area with a usage example for customising this element.