Read more about this book

(For more resources on Drupal, see here.)

Introduction

Sub-themes of core and contributed themes are convenient and efficient in modifying and reusing elements of their base themes, circumstances often require a completely unique approach specific to our site. Custom themes are the solution for websites which demand a fresh look, using complex layouts, or need so much customization that it would be prudent to start with a clean slate.

Custom themes are the equivalent of handcrafted pieces of art as the themer controls every piece of the puzzle from a design or implementational point of view. This includes setting up the theme using .info files, choosing the layout, implementing it in a page template, adding regions, styling nodes using node templates, blocks using block templates, and so on. But over time, developers have identified a list of common tasks, characteristic layouts, and file and folder hierarchies which are logical, efficient, and promote reuse. This has evolved into what have been dubbed starter themes, themes upon which custom themes are built, usually as sub-themes.

The most popular starter theme for Drupal is Zen. As advertised on its project page, the Zen theme is a flexible standards-compliant and semantically correct XHTML theme that can be highly modified through CSS and an enhanced version of Drupal’s template system. It is designed in modular fashion making it straightforward to change layouts, override templates and theme functions, and to add or remove features. Additionally, the Zen theme comes with extensive documentation within each file which make things all the more convenient.

With respect to CSS, Zen maintains a number of well documented CSS files segregated by functionality or location. For example, layout rules are contained within a dedicated layout.css (or similar) file and page backgrounds are styled within page-backgrounds.css and so on. This makes it convenient when it comes to managing and tracking code changes.

A Zen-based theme contains the following file and folder structure:

File/folder name	Purpose
template.php	A file where theme overrides and other theme and engine-related code is placed.
theme-settings.php	A file where settings particular to a theme can be placed. These settings are usually exposed on the theme’s configuration page.
css/	A folder to store stylesheets.
images/	A folder to store images used in the theme.
images-source/	The folder where the source files for the optimized images in the images folder are available.
js/	A folder to store JavaScript files.
templates/	A folder where tpl.php template files are to be placed.

There are a number of other starter themes available on drupal.org. Some of the more popular ones include Fusion (http://drupal.org/project/fusion), Blueprint (http://drupal.org/project/blueprint), Ninesixty (http://drupal.org/ project/ninesixty), and Adaptivetheme (http://drupal.org/project/ adaptivetheme). We will be looking only at the Zen starter theme in this article.

Clearing the theme registry

Before we begin, we need to familiarize ourselves with a seemingly trivial yet crucial task that needs to be performed on a routine basis during theme development—clearing the theme registry. The theme registry is essentially a table that Drupal uses to list and track the files and features of a theme, as well as the theme functions which are being exposed by modules and the theme itself.

While it is recommended practice to turn on Drupal’s cache feature only for production sites, the theme registry is built and cached regardless of other caching options. As a result, any changes that affect the structure of the theme will necessitate the clearing of the theme registry.

Getting ready

Rebuilding the registry is an intensive operation which is required only when changes have been made to the theme’s files.

How to do it…

There are a number of ways of clearing the registry. In a stock Drupal installation, visiting admin/settings/performance (Home | Administer | Site configuration | Performance) and clicking on the Clear cached data button will clear all cached data, including the registry, and force a rebuild.

A shortcut
It is sometimes handy to know that the cache and registry can also be cleared by visiting admin/build/themes (Home | Administer | Site building | Themes) and just clicking the Save configuration button.

However, during development or debugging, we will want to clear the registry with great regularity. Rather than having to do so manually, it is often handy to be able to instruct Drupal to perform this operation automatically on every page load. Some themes, including the Zen-based theme which we will be familiarizing ourselves with later in this article, offer an option on their configuration pages to rebuild the registry on every page load. While this is certainly convenient, the recommended method of managing this and other development-oriented operations is through the use of the Devel module.

As the name suggests, the Devel module is one which is tailor-made for use during development. It can be downloaded from http://drupal.org/project/devel. Once the module has been downloaded and installed, navigate to admin/settings/devel (Home | Administer | Site configuration | Devel settings) where the option to Rebuild the theme registry on every page load can be enabled.

How it works…

Drupal maintains a cache of all .info files, template files, and theme functions in the theme registry. This registry is a part of the cache table in the Drupal database. When we click on the Clear cache data button in the performance settings page, all Drupal is doing is clearing this entry in the cache table, which automatically forces a rebuild of the registry. The Devel module does the same thing when the Rebuild the theme registry on every page load setting is enabled, except that it does this automatically on every page view.

It is important to keep in mind that rebuilding the registry, or for that matter, clearing any of the caches is an expensive operation which adversely affects the performance of the site. Therefore, it is recommended that this setting only be enabled during development and not in production sites.

Clearing the registry is an important factor to keep in mind during development and especially during debugging.

There’s more…

The Devel module also provides a block with handy shortcuts to oft-used areas of the site.

Clearing the cache using the Development block

The Devel module provides a Development block which can be enabled via the block management page at admin/build/blocks (Home | Administer | Site building | Blocks). Once enabled, the block lists, as in the following screenshot, a number of links to perform operations such as emptying the Drupal cache, rebuilding the menu cache, and even reinstalling modules. Emptying the cache will also force a rebuild of the theme registry.

Creating a theme from scratch

While we have previously looked at installing contributed themes and extending base themes using sub-themes, this recipe will outline the steps required to create a custom theme.

Getting ready

It is assumed that the sites/all/themes folder has already been created. This is the recommended location to place custom and contributed themes.

How to do it…

While creating a brand new custom theme, files such as page.tpl.php will need to be explicitly defined and there is no base theme.

1. Create a folder with the new theme’s name inside the sites/all/themes folder.
   In this example, we are going to call our theme mytheme.
2. Create a file named mytheme.info and open it in an editor.
3. Add details about the theme as follows:

   name = My theme
   description = My custom theme
   core = 6.x
   engine = phptemplate

4. Save the file.
5. Visit the theme administration page at admin/build/themes (Home | Administer | Site building | Themes) and we should be able to see a new entry for our theme.

   

6. Enable the theme by checking its Enabled checkbox.
7. Also, set it as the default theme by selecting its Default radio button.
8. Click the Save configuration button at the bottom of the page to save the changes.

How it works…

Just as with other themes, Drupal scans the sites/all/themes folder looking for .info files which indicate the presence of a theme. Seeing mytheme.info, it parses the file and loads the details of the theme, and saves them in the database.

When the new theme is enabled, what we will see is largely unstyled content not unlike the following screenshot. The problem here is that we have not specified any CSS stylesheets to ay out the page. The only styles being loaded are those that are module-specific as opposed o theme-specific.

The styles being used in the preceding screenshot are as follows:

<link type="text/css" rel="stylesheet" media="all"
href="/mysite/modules/node/node.css?u" />
<link type="text/css" rel="stylesheet" media="all"
href="/mysite/modules/system/defaults.css?u" />
<link type="text/css" rel="stylesheet" media="all"
href="/mysite/modules/system/system.css?u" />
<link type="text/css" rel="stylesheet" media="all"
href="/mysite/modules/system/system-menus.css?u" />
<link type="text/css" rel="stylesheet" media="all"
href="/mysite/modules/user/user.css?u" />

As we can see, the only stylesheets in evidence are those belonging to core modules and none from our theme. In addition, Drupal has noticed that we do not have any template files in our theme, most notably, page.tpl.php. Therefore, it has loaded an inbuilt page template file from modules/system/page.tpl.php and used it instead. Similarly, it is using the node.tpl.php file from modules/node/ as the basis for each node’s layout.

In other words, we have a lot of work ahead of us in getting things up and running especially if our eventual requirements are going to be complicated. As we will see in the next recipe, this is one of the reasons why most themers prefer to use a starter theme and hit the ground running.