Drupal 6 Theming Cookbook: Over 100 clear step-by-step recipes to create powerful, great-looking Drupal themes

Downloaded themes are usually in tar.gz format. These files can be extracted using archive programs such as 7-Zip (http://www.7-zip.org) as well as commercial packages such as WinZip (http://www.winzip.com) and WinRAR (http://www.rarlabs.com).

To install a theme, open Windows Explorer and navigate to the Drupal installation.

In the last screenshot, we can see that the contributed theme Acquia Marina has been enabled and is set to be the default theme for the site. Drupal comes packaged with six core themes including Bluemarine shown in the last screenshot.

Click on Save configuration to enable the new theme and also set it as the default theme for the site.

Drupal scans folders within sites/all/themes and, in particular, looks for files with the extension .info. This file contains information about the theme such as its name, description, version compatibility, and so on. If the theme is compatible, it is listed on the theme administration page.

A site can have multiple themes enabled. Out of these, only one can be chosen as the default theme. The default theme is, as the name suggests, the primary theme for the website. When more than one theme has been enabled, users with the select different theme permission can optionally select one of the other available options as their personal theme.

Drupal makes it easier for us to manage our site by following preset naming conventions when it comes to the folder structure of the site.

The new logo should be in a suitable format and should balance quality with size. The usual rule of thumb is as follows:

Adding a custom logo to a theme can be done using the following steps:

The uploaded file is saved in the Drupal filesystem and the path to the logo is registered as a configuration setting in the database. During display, the theme uses this setting to embed the logo within the Drupal page. The following screenshot displays the Bluemarine core theme with its default logo replaced with a custom PNG.

Besides specifying the logo file via a theme's configuration page, there are other avenues which can also be pursued.

We are going to need the icon file to be added which is recommended to be of size 32x32 pixels or higher. An example icon file named favicon.ico can be seen in the misc folder in the Drupal installation.

Adding a custom favicon to the theme can be done by performing the following steps:

The uploaded file is saved in the Drupal filesystem and the path to the icon is registered as a theme setting in the database. When a page is being rendered, the Drupal theme system designates this .ico file as the favicon for the site.

In the following screenshot, we can see the logo image added in the previous recipe also being used as the basis for a favicon:

Besides manually uploading the icon file via the theme's configuration page, other options exist to perform the same task.

Think up a good slogan! This is the biggest stumbling block to getting this recipe right.

Adding a slogan to a theme involves the following steps:

Drupal saves the provided slogan as a configuration setting in the database. The theme system makes this setting available as a variable to the theme which outputs it accordingly when the page is being rendered.

In the following screenshot, we can see that the slogan is enabled and is displayed below the logo and name of the site.

Besides the site slogan, other site variables are also available on the theme configuration pages.

Since we are going to be working with multiple themes in this recipe, we will need at least two themes to have been enabled on the site. This can be done via the theme administration page at admin/build/themes (Home | Administer | Site building | Themes) as seen earlier in this chapter.

We can enable users to choose between the different themes which are available through the following steps:

Drupal saves the users' choice as a configuration setting in the database. When a page is to be displayed, Drupal notices this setting and themes the page using the specified theme instead of the site's default theme.

Depending on the amount of real estate required, it will be worthwhile to put some thought into deciding on the right theme to use as the administration theme. Themes such as the aptly named Administration theme (http://drupal.org/project/admin_theme) and RootCandy (http://drupal.org/project/rootcandy) have been designed specifically with the administration pages in mind. That said, if the requirement is temporary, using a core theme such as Garland will usually suffice.

Specifying an administration theme can be done by following these steps:

Viewing an administration page should confirm that the specified administration theme is being used in preference to the default theme.

Every time a page is displayed, Drupal checks to see if the URL of the page begins with admin. If it does, and if we have specified an administration theme, Drupal overrides the default theme being used with the specified theme.

For this example, we will be adding a Who's online block to the left sidebar region (assuming that the theme has declared such a region). The position of a block both in terms of region as well as its weight (which determines its order among other blocks in the same region) can prove to be very important in terms of usability and exposure.

The Who's online block can be added by following these steps:

The block should now be visible in the left sidebar as can be seen with the Garland theme as follows:

Drupal maintains a table named blocks in its database which contains a list of all the blocks exposed by the modules in its installation. By moving the Who's online block to the Left sidebar region, we are effectively just manipulating this table in the database. When a page is displayed, Drupal uses this table to determine the status and location of each block for the current theme and the theme system positions them accordingly.

Block layouts are particular to each theme and can therefore be customized accordingly.

For this recipe, we will be adding a simple welcome message in a custom block within a predetermined region. As with standard blocks, position matters!

The following procedure outlines the steps required to add a custom block to a theme:

Just as with standard blocks, Drupal maintains a table named boxes which tracks all custom blocks including their content and input format. Once a custom block is enabled, it is added to the blocks table and tracked as if it was a standard block.

When created, a custom block appears in the block list and can be treated just like any other block. It can be dragged around different regions, have its visibility settings controlled, and so on. The following screenshot displays our newly created welcome block:

Custom blocks are useful in rendering more than just simple text strings.

The front page is a special case on most sites as it usually showcases the rest of the site. Manipulating block visibility for front page blocks is a frequent requirement and, in our case, we are going to ensure that the welcome message block is only going to be displayed on the front page and nowhere else.

Block visibility is controlled from the block's configuration page as follows:

Whenever a block is to be displayed, Drupal checks to see if we have any visibility settings applied to it. In this case, we have Show on only the listed pages switched on. As a result, Drupal checks the Pages textarea to see which pages have been listed. The use of the <front> keyword, which is a special indicator that represents the front page of the site, tells Drupal that unless this is the root of the site, this block should not be displayed.

This is all done before the content of the block is processed by Drupal thereby improving performance and making this method cleaner and more efficient than hiding the block using CSS or elsewhere in the theme.

Drupal offers a number of page-matching options to further help refine when and where we display our blocks.

<front>
user/*

For this recipe, we will be configuring the welcome message block which we created in an earlier recipe in this chapter, to only be visible to authenticated users.

Controlling block visibility is handled from the block administration pages as outlined in the following:

Drupal maintains a table named block_roles which keeps track of role-specific settings for all blocks. Changes made to role settings on the block configuration page are stored in this table. When an anonymous user now visits the site, Drupal will not display the Welcome message block.

We will be configuring the Recent comments block—which is provided by the Comment module—to only be visible for the story and blog node types. While the story type is enabled by default, the blog type is created only upon enabling the Blog module from the module administration page at admin/build/modules (Home | Administer | Site building | Modules).

It is assumed that both the Blog and Comment modules have been enabled, and sample nodes and associated comments have been created.

Block visibility can be configured from the block's configuration page as per the following steps:

Since we have chosen to control block visibility using PHP, Drupal evaluates the code within the Pages text area and only displays the block if it returns the value TRUE.

The variable $types contains the list of allowed node types. This list is populated with the internal names of each node type which can be accessed via the Content types page at admin/content/types (Home | Administer | Content | Content types).

In the previous screenshot, the internal names of each type are listed under the column titled Type.

Since blocks are not restricted to only be visible on node pages, we need to ascertain if the page that is currently being viewed is a node page. We do this by checking the path to see if it matches the pattern node/node-id. In other words, we only consider displaying the block if the path involves the word node followed by the node ID, an integer.

Once we have ensured that we are viewing a node, we need to get Drupal to load the node using the node_load() function so that we can check if its type matches one of the types that we have allowed.

If the type of the node being viewed is in this list of allowed types, then the in_array() call returns TRUE and the block is displayed. Else, it returns FALSE which leads to the block not being displayed.