Question

I’ve recently been given an existing Drupal project, and asked to improve the front-end (HTML, JavaScript, CSS). I have loads of front- and backend development experience in Django, PHP, Ruby, etc, but I don’t have any prior Drupal experience, and figuring out what’s going on in the project is proving to be troublesome at best.

Can anyone give a rundown (or provide some links) of how a typical Drupal site sticks together, and what I have to do to add page elements, change the CSS and add JavaScript functionality? What are the appropriate places for this?

It would have been great, of course, to ask the developer of the code what’s going on – but he’s nowhere to be found.

---

Here’s what I’ve seen so far, from about 2 hours of scratching around in the code and online:

There are loads of modules, and the theming files (CSS, some images) are located in sites/all/themes/theme_name/…

The HTML files (templates) seem to be randomly scattered all over the place – in modules, *.tpl.php files, etc.

The theme has a .info file, containing definitions for regions, among other things. These regions correspond to variables in the template files – but where are the variables defined / edited?

---

This is making me pull the hair out of my head, any help with how to change the front-end would be great!

Answer 1

In the long run, using a theme framework like Zen (assuming there’s budget for more than a few hours of light updates) is a good approach especially for a Drupal beginner, since the developers of Zen have thought through all the many details that allow a theme to work well across many different sites and browsers.

Maybe I’m misinterpreting Scott’s suggestion, but I think his main point is that by examining the Zen framework, you will learn best practices. This is also true – looking at existing themes and theme frameworks is a great way to see how the template.php file should be structured, for example, and how JS files should be included.

In terms of details of implementation, there are some basics that will probably help you get a running start:

Regions/Blocks:

• when you define a region in the info file, such as regions[header], the $header variable then becomes available to you in your page template (such as page.tpl.php). When you create a new region, in order to access it in your templates, you will need to clear your theme cache. You can include your region anywhere in your page template by printing out the variable:

  <?php print $header; ?>

  Once your regions have been added, you typically use Blocks to populate that region. The Drupal documentation about blocks is here. You can create new blocks manually by clicking “Add Block.” You can also generate new dynamic blocks by creating a new View (see below). Blocks are also often added by modules when they’re installed.

JavaScript/jQuery:

• you can include JavaScript files either with drupal_add_js() in your template.php or by including them in your info file like this: scripts[] = js/myscript.js. You will also need to clear your theme cache anytime you modify your info file.

  If you’re using Drupal 7, this page gives you a great overview of how to structure your JS files and how to include them in your theme. For Drupal 6 (or 5), this page covers those topics.

  You probably know this already, but the jQuery library is already included in Drupal. The version of jQuery is usually lower than the current released version, though if needed you can update at least to a somewhat higher version using jQuery Update.

Views/CCK

• If there are any tpl files in the theme that start with views or node-/node--, they are probably overriding Views/content types. You may want to get to know at least the basics of CCK/Views, as these form the basis for many tpl.php overrides. You may not be creating new Views or content types, but if the previous developer did, they likely created some tpl files to override one or both. Assuming Views is installed and your user role has access to it, have a look at the various Views to see how they work. If a tpl.php file starts with views, it’s overriding something in a View. If it starts with node (except node.tpl.php, which is a generic template for all Drupal nodes), it’s typically overriding a content type (which are typically created using the CCK module).

  A key aspect of tpl files is that like CSS, they have a specificity cascade. So, in Drupal 6, if you have a page.tpl.php, this will be the template for all the pages on your site. However, you can override it for your front page with the template page-front.tpl.php. Similarly for node.tpl.php. If you have a content type called Event, you can override the node template with node-event.tpl.php. Understanding this concept will help you make sense of tpl naming conventions.

One last point, and this is something that will probably take a little while to get used to, a common issue for new Drupal themers is that they see they can use a template every time they want to override something in the interface. So, when they want to override five pages or content types, they create five templates. This “works” but it is often overkill and can create maintenance issues. As you become more comfortable using Drupal’s theme system, you’ll find you are creating fewer and fewer page--blah-blah.tpl.phps and doing more template overrides in template.php, which is where most of the theme logic should ideally reside. This helps you consolidate (and re-use) your template overrides. If budget/time is not too tight, get to know the template.php functions.