The role of themes in the Drupal system relates to the presentation layer of a website, that is, what the site visitors and administrators experience through their browsers. The files in a theme provide HTML formatting, CSS styling, and additional logic that frames the output of the system's functionality. All of these elements come together to create what the site visitor sees in their web browser.
While the default Drupal distro includes a set of themes which will be sufficient for many users, I assume you are reading this book out of a desire to do more, whether it be only to install additional themes and then modify them to suit your needs, or whether you plan to build your own themes from scratch.
In order to grasp better some of the challenges (and opportunities) associated with the Drupal themes, it is useful to look at three key concepts that impact the way you use the system and the way in which you must plan your theme deployment.
We're going to look next at three key concepts relating to Drupal themes. Those three concepts are:
1. You Can Theme It All
2. Build with Blocks
3. Intercept and Override
One source of confusion for many new users of Drupal is the fact that the default administrator interface is the same as the front-end interface seen by site visitors. Unlike other content management systems, there is not a purpose-built administration interface in Drupal.
During the installation process, the system is configured to display the Garland template for both the front end and the back end. This is yet another example of the high level of integration typical to Drupal. If you want to work with one consistent template throughout, you can.
The seamless integration of the administrator interface into the site works well in some cases, but in others it may be problematic. There will be situations where the use of the same theme for the visitors and the administrators is undesirable, for example, on a marketing-oriented site where the artistic theme used for the site visitors may be impractical for site administrators.
The system's default use of the same page template for both the front end and the back end conceals the existence of a great deal of flexibility and makes it non-obvious that you can do more with the themes. That's the bad news. The good news is that you can do more—much more!
The Drupal system allows you to specify different page templates for different purposes on your site. You can, for example, build one page template for your home page, another for your interior pages, and yet another for your administrator's use. The sky is the limit on this point as the templating engine also gives you the ability to provide a variety of styling for very specific types of contents or for the output of a particular module. The control is highly granular and with a little practice (and a little ingenuity) you will find the system to be very flexible indeed.
In the following chapters, we will look at how to implement multiple themes and how to theme and configure all the various constituent parts of the Drupal system. You can theme it all!
As noted earlier in this chapter, the code of a Drupal theme includes placeholders called regions. The regions are areas in a page where content will be displayed. The site administrator can then assign a variety of output to the regions through the admin interface.
One of the most common sources of output is the Drupal modules. Modules are stand-alone bits of code—mini applications in some cases—that extend the functionality of your site. The default distro includes a large number of modules. It is through modules that Drupal provides functions like the Forum, the Aggregator and even additional administrative power, like the Throttle module.
Some modules produce output that appears on the screen, for example, the Forum module produces a threaded discussions functionality with extensive output. Other modules simply add functionality, for example the Ping module, which notifies other sites when your content has changed. The administrator is able to toggle modules on or off and able to assign the output of those modules—called blocks—to the various regions in the theme.
The process of activating modules and assigning blocks to regions on the pages is one of the most basic and most important skills for a site administrator. Understanding how to administer the system and what options are available is key to building interesting and usable sites. A great deal of flexibility can be squeezed out of the system in this area alone.
This system, however, is not without complications. Module developers typically build their modules to be self-contained units. This independence also extends to the presentation layer of these discreet items of code. As a result, almost all the modules have distinct formatting and specific files that control that formatting. This approach to programming and modularization leads to a system in which a significant number of discrete units must be dealt with, adding greatly to the potential for complexity in changing the look and feel of a site to your specifications.
The list of default modules available in Drupal
Each of the functional units above—each module—is kept in a separate directory inside the Modulesfolder. Many contain their own CSS files, creating a large number of style sheets scattered throughout the system. Add to that already daunting collection of modules any additional extensions you wish to install on your particular site and you can see how CSS juggling might come to dominate your life. Nevertheless, fear not, as styling all of this is manageable, using the technique discussed below.
In addition to the blocks produced by modules, you can also create blocks specific to your installation. Manually created blocks provide an easy avenue for placement of additional information (e.g., text or images), or, by inclusion of PHP code in the block, additional functionality.
Each of the blocks in the system, whether created by modules or manually created by the system administrator, can be themed individually, if you so desire.
The process of getting data from its raw form to its final displayed form provides several opportunities for you to affect the output prior to the data's arrival on the viewer's screen. While it is possible to work at the lower levels—hacking the core or the modules or the templating engine—I advise against that. The recognized best practice approach to customizing themes emphasizes making changes at the higher levels, primarily to the theme files themselves.
The best practice approach to customizing themes involves intercepting and overriding files and styles—not altering the core. In short, if you wish to style a particular block, instead of hacking the module that produces it, you will override the default module file with one of your own, or you will intercept the styles or functions of the module with your own; most likely, you will use a combination of both those techniques. The new files and styles you create will be part of the theme itself.
By choosing to affect the system's output at the highest levels of Drupal's processes, we leave the core in a purer state. This approach has several advantages, the most significant being that system upgrades and patches can be applied without fear of losing modifications necessary to your presentation. Sites customized in this manner are easier to maintain and your code remains portable and available for re-use in other deployments.