Home Classroom Drupal


Part 8 – Moving from Drupal 5 to 6

As Drupal 6 becoming a solid platform and most of the contributed modules now supporting the new platform, one might need to migrate his older Drupal 5 site to 6. In this episode we would be looking at key changes in Drupal 6 that should be considered when adopting the new platform.

Schema API

In Drupal 6, a new Schema API has been introduced to allow modules to declare their database tables in a structured array replacing the need to write raw SQL queries in older versions. This schema structure is similar to how Form API operates and provides API functions for creating, dropping, and changing tables, columns, keys, and indexes. Further, this schema provides a convenient, DBMS independent system to define your tables.

With the introduction of Schema API, a new hook to integrate schema have been introduced as well. You can implement hook_schema in your module install script to use this new awesome improvement.

This is an example of how a simple Drupal schema definition will look like inside the hook_schema.

New Formats for hook_install and hook_uninstall

The format of hook_install has been changed to the following. Instead of writing SQL queries within your hook_install, just call drupal_install_schema() to invoke hook_schema and setup your tables.

In hook_uninstall use the following format.

New Syntax for .info Files for Modules

Now you can define your dependencies in your .info file in the module. Also, you can define the Drupal version compatible with your module as well as PHP compatibility.

name = Forum
description = Enables threaded discussions about general topics.
dependencies[] = taxonomy
dependencies[] = comment
core = 6.x
php = 5.1
Introduction of .info Files for Themes

Now you can define your regions simply inside your new .info file in the template directory. The format would be as follows.

name = mytheme
description = MyTheme description
version = VERSION
core = 6.x
engine = phptemplate
regions[left] = Left sidebar
regions[left_extra] = Left extra sidebar
regions[content] = Content
regions[content_extra] = Content Extra

Using Theme Registry

If you want to override a theme used in a hook through one of your templates, here is how you do it. Override hook_theme in your theme’s template.php file and follow the given format. Here search_form is the hook and mytemplate.tpl.php is the custom template that will be used to theme the output from the hook. For more complex overriding behaviours, study the hierarchy of Drupal theming system given in Figure 1.

Figure 1: Drupal theming hierarchy
(Source: About overriding themable output – http://drupal.org/node/173880)

Introduction of Preprocessor Functions

Preprocess functions applies only to theming hooks implemented as templates and the main role is to setup variables to be placed within the template (.tpl.php) files. This is a good attempt at removing the ugliness of _phptemplate_variables($hook, $vars) in older versions.

If you want to add/modify variables introduced through a hook named foo and if your theme is named ‘mytheme’ then you do the following.

Template Suggestions

Last but not least, the template suggestion system in Drupal 6 is worth a look at. For custom suggestions, you have to define your theme_preprocessor_page function in your theme and add template suggestions/variables that would be passed to the page template.

The following code will add template suggestions to the Drupal rendering system so that all the node renderings would look for a template named “page-node-{content_type}.tpl.php”

More, more and more!

This episode only touched the tip of the iceberg that is Drupal 6. For more information on changes from Drupal 5 to 6, check Drupal 6 theme guide (http://drupal.org/theme-guide/6) and Drupal 6 module migration guide (http://drupal.org/node/114774).


Sliding off the usual chattering on Drupal 5, in this article I thought of peeking into Drupal 7, which is the blooming new horizon for Drupal community. The release date of Drupal 7 is whispered in shadows, out of the reach of common mortals but the development snapshots are available for anyone to grab.

[Dries Buytaert - http://buytaert.net/drupal-7-code-freeze-almost-upon-us]


Big question – What’s new in Drupal 7

The main difference you will notice might be the way Drupal is interacting with Database. In addition to integrating PDO and better support for multiple Database servers, hook_install, hook_uninstall will now automatically handle schema definitions.

Another awesome addition is how File API accesses files with the use of stream wrappers. All functions that used to take a file path now take a URI like public://old_photos/banana, bringing file paths to a common format. The Drupal 7 core ships with three default stream wrappers namely temp://, public://, and private:// with support for contrib to offer wrappers such as s3:// for Amazon S3, flickr:// for getting data into/out of Flickr and many more. Just this single feature could bring a totally new awesomeness to the Drupal community and much time saving for future Drupal developers.

In terms of field API improvements, taxonomy terms are now fields while comments and taxonomy terms have been made fieldable, and fields are also now translatable which is a go go for Internationalization(I18n) aspect.

Performance-wise, one of the major downfalls of Drupal was the bloated load speed of a default Drupal instance. With D7 this issue has been approached by shipping a “smushed” images that are lighter on bandwidth, and with a caching system to the render API which is currently implemented by blocks, and because it happens early in the page render cycle, it works for both authenticated users and with node access modules.

Another issue that has been fixed in D7 is improvements in Install profile. Instead of .install and .info files working just as identifiers for a module, now they can declare dependencies, manage dependencies, version management and many more.

Regarding Drupal templates, the most exciting improvement might be the addition of wildcards operator in tpl.php files. For example page-user-%.tpl.php to affect any user/xxx while letting page-user.tpl.php affect only the actual page /user could save many unnecessary woes for template designers. Also the AJAX framework from CTools has been brought into the core, and core now supports a new .once() method for ensuring that an AJAX behaviour/effect applies only a single time which can save much code space. Additionally, there are now system-wide classes for marking elements as either completely hidden (.element-hidden: equivalent to jQuery’s hide() function) or invisible (.element-invisible: visible only to screen readers).

Drupal 7 Admin interface [http://www.drupalcoder.com/story/526-drupal-7-whats-new-from-an-end-user-perspective]


Is that all ?

No, but listing all new stuff of D7 here would be boring and frankly tiresome to most. But if any one is interested to have a look at all the new changes that will be rolled out with Drupal 7 the best place would be the release note update of D7.

With a development time scope of more than 2 years, the arrival of Drupal 7 is sure to bring much excitement and many new cool features (in addition to the few listed here) to the Drupal community. Till the official announcement, let’s keep fingers crossed!


Let’s build a module (Part 3)


In last two articles on Drupal, we discussed some basic steps in creating a module and how to setup the database tables. It’s now time to see actually how the module script should be written to implement the functionality required.

When it comes to writing the module script (.module file), the most important items are hooks. Drupal hooks are used to extend the functionality provided by the core modules and there are some key hooks that are essential in almost all modules we write.

1.Hook Menu – hook_menu($may_cache)

This hook enables modules to register paths, which determines whose requests are to be handled. Depending on the type of registration requested by each path, a link is placed in the the navigation block and/or an item appears in the menu administration page (q=admin/menu).
Drupal will call this hook twice: once with $may_cache set to TRUE, and once with it set to FALSE. Therefore, each menu item should be registered when $may_cache is either TRUE or FALSE, not both times. Setting a menu item twice will result in unspecified behavior.
For a detailed usage example, see page_example.module.

2. Hook Block – hook_block($op = ‘list’, $delta = 0, $edit = array())

Declare a block or set of blocks.
Any module can export a block (or blocks) to be displayed by defining the _block hook. This hook is called by theme.inc to display a block, and also by block.module to procure the list of available blocks.

3.Hook Perm – hook_perm()

Define user permissions.
This hook can supply permissions that the module defines, so that they can be selected on the user permissions page and used to restrict access to actions the module performs.

4. Hook Help – hook_help($selection)

Provide online user help.
By implementing hook_help(), a module can make documentation available to the engine or to other modules.

Now let’s see how these hooks can be integrated into a single module script to build our computer parts module.

First part is adding a hook menu which decides how to handle URLs coming to the module and where to direct them. Add this snippet to our previously created computer_store.module script.

In above code we have implemented our hook menu in computer store module. It defines two URL paths and what should be the action taken when each path was followed. These paths are ordered as a set of associative arrays and return at the end of the hook. Let’s try to understand the meaning of this menu array.

#title – Defines the title of the page to direct
#path – The path which the action should be taken upon visiting
#callback – This is the function that’s called when this path is followed
#callback arguments – The argument given here will be input to the function defined in #callback as an argument
#type – The type of this menu link
#access – What type of users can access this URL. Here we usually use user_access() function to check if a given permission is available to the current user. In above example, it checks if the current user has “’administer site configuration” privileges (which can be set from the Administer > User Management) and if not denies the access to such users.

For more information on hook menu check this URL.

Now add a simple form function named ‘computer_store_configure_form’ as defined by our earlier menu call back in our hook_menu. For the moment let’s just add a dummy form function and in next week let’s discuss thoroughly on how to improve our module using Drupal form API.

Now uninstall our module through Drupal module manager if it was previously installed and reinstall the module. Now you will notice that there’s a menu item in administer > Site configuration section named “ Computer Store” and clicking it will take you to the admin section of our newly created module.

Through this article we have seen how to setup a hook menu and in next article let’s see how to complete this module with Drupal Form API.


Let’s build a module (Part 2)


From previous article, we have taken the first steps in writing a Drupal module. Before going any further let’s revisit the basic steps of creating a Drupal module.

1. Creating the module folder
2.Creating the .info file
3.Creating the .module file
4. Installing the module

Little bit more

Other than the absolute basics of writing a Drupal module given above, there are some other tidbits that become handy when working in real world. For example, in more occasions than not, Drupal modules have to interact with a database to manage its data. Therefore Drupal has provided mechanisms to easily execute such operations.

Interacting with Drupal DB

If a module required to create a table structure at the installation or setup variables in the database as placeholders (to store module settings.etc), Drupal allows the developer to implement this through .install scripts.

Revisiting last article example where we started creating our customized module named computer_store, we will be required to have at least one tables to manage computer part indexes. Therefore let’s initiate this table through our .install script.


1. Create a file named  computer_store.install within our previously created module folder computer_store.

      2. Add an install hook to the script as follows. Within this hook state the SQL script you want to run at the module installation.


// computer_store.install

function computer_store_install() {
switch ($GLOBALS['db_type']) {
case ‘mysql’:
case ‘mysqli’:

db_query(“CREATE TABLE {computer_store_index} (
store_index int unsigned NOT NULL AUTOINCREMENT default ’0′,
part_name varchar(32) NOT NULL default ”,
price float unsigned NOT NULL default ’0′,
PRIMARY KEY  (store_index)
) /*!40100 DEFAULT CHARACTER SET utf8 */;”);

case ‘pgsql’:
db_query(“CREATE TABLE {computer_store_index} (
store_index serial CHECK (store_index >= 0),
part_name varchar(32) NOT NULL default ”,
price float(10) NOT NULL default ’0′ CHECK (price >= 0),
PRIMARY KEY  (store_index)


Explanation of the code:


At the installation of any Drupal module, if there exists an  install hook (computer_store_install) like in the above code, it’s called and code is executed. The PHP global variable ‘db_type’ ($GLOBALS['db_type']) keeps the database type of the Drupal instance and thus allows you to provide compatibility with a wide range of SQL database management systems such as MySQL and PostgreSQL.  Drupal’s db_query function (http://api.drupal.org/api/function/db_query) used above provides a high level interface to query databases so it can be used to query various SQL databases.

Other than creating tables, we can also set variables in the Drupal database to keep various module settings. For example to keep the maximum allowed number of computer parts in the store, we can set a variable named “maximum_store_parts” in the database. To do this add the following line to our previous computer_store_install hook.

variable_set(“maximum_store_parts”, 10000);

Removing the module

As well as providing a mechanism to create a table structure, there needs to be a way to remove created tables when the module is being removed. For this Drupal provides an  uninstall_hook. To remove the table we created in our install_hook when the module in uninstalled, add an uninstall_hook to our computer_store.install script.


function computer_store_uninstall() {
db_query(‘DROP TABLE {computer_store_index}’);


cache_clear_all(‘*’, ‘cache’, TRUE);


Explanation of the code:

When the computer_store module is uninstalled from the Drupl backend, function computer_store_uninstall is called and we use the same db_query method to remove the previously created computer_store_index table from the Drupal database. Then the method variable_del is called to delete the variable maximum_store_parts from the database, which was set when the module is installed from the install hook. Then optionally we call cache_clear_all targeting Drupal ‘cache’ table to remove any stored cache in regards to the removed module.

Updating the module

In case we need to update our module table structure at a later time (usually some time after the module is released), we can add an update hook to our module and release a new version of our module so when users update their Drupal instances the module will also get updated.

Each update is placed in a modulename_update_x() function (where x is an incrementing integer) and updates should always increment by 1.

function computer_store_update_1() {
$items = array();
$items[] = update_sql(“ALTER TABLE {computer_store_index} ADD description”);

Note that if you add an update hook to your .install file you need to also update the install hook so that it contains the latest code. When a module is installed the first time, only the install hook will be fired and it will assume that is most current. Update hooks are only used when updating an existing installation.

More Support Materials


Writing .install files – http://drupal.org/node/51220

Hook install – http://api.drupal.org/api/function/hook_install/5

Hook uninstall – http://api.drupal.org/api/function/hook_uninstall/5

Hook update – http://api.drupal.org/?q=api/function/hook_update_N/5

Hook cache clear – http://api.drupal.org/api/function/cache_clear_all/5


Part 4 – Let’s build a module (Part 1)

When we take Drupal developments as a whole, it can be separated into two main parts; Developing Drupal themes and module developments. Within this article we’ll be focusing on how to get on with Drupal module development process.


Drupal Modules

Drupal modules are the building blocks and the workhorse of a Drupal site. Since at the first installation Drupal only gives just a barely running site,  usually all other customizations and special workload is carried out by various modules.


A Drupal site can have three kinds of modules.

1.      Core modules that ship with Drupal and are approved by the core developers and the community

2.      Contributed modules written by the Drupal community and shared under the same GNU Public License (GPL)

3.      Custom modules created by the developer of the website.


From the Drupal modules download page you can find hundreds of readily available ‘Community contributed modules’ that can be downloaded and installed on a whim. But on the other hand, if there are any custom tasks that you need to be carried out through the site, you will have to develop it yourself and install it same as any other contributed module. Also sometimes you’ll have to modify existing contributed modules to suit your project requirements so you have to take a look at the code and hack it. On the other hand, if there’s any wrong with the existing code of a contributed code you can just fix it and send a patch to the patch queue of that module project. So for all of the above mentioned, it’s absolutely necessary to have a knowledge of the Drupal module development process and how to read a module.


So let’s get in to the action.


The Goal

We have computer storage and in need of a web based store backend to keep track of items stored and sold. So we will be developing a Drupal module for this task with the intention of scaling it to add a shopping cart in the future.



Getting Started

Within every module, it’s required to have at least two files.

1)      Info file – a file with the extension of “.info” to provide information about the module to Drupal site

2)      Module file – a file with the extension of “.module” as the main execution point of the module


Other than above two, there can be other files in a Drupal module that work mainly to break tasks of the module to small sections.


1)      Install file – a file with the extension of “.install” that provides that database creation instructions when a module is installed and uninstalled

2)      Include files – although not specifically designed for a Drupal implementation, as a general rule include files with the extension of .inc are used to form small libraries that can be later included in to a main script


So we have to get some of these files in our hands for our first module.


Step 1  – Create the module folder

 If we are not working on a mulitsite configuration, we have to create a folder with the name of our intended module name in ‘/sites/all/modules’ (as of Drupal 5.x). But if you are in a multisite configuration the folder should be created in your intended site configuration (e.g. sites/yoursite.com/modules) and for the sake of simplicity let’s work on a single site (without any multisite complexities) for our first Drupal module creation.


Let’s name our first module as computer_store and create a folder with the name computer_store in ‘/sites/all/modules‘ of your Drupal deployment.


Step 2  – Creating the .info file

Now we have to let Drupal know about our new module through a .info file. So let’s create it as our first file in our module directory.

Create a file named  computer_store with the extension of .info (computer_store.info) in your computer_store directory and enter following.



name = computer_store
description = “A module to manages our computer store details”
package = “E-Commerce”



For a simple briefing of the lines in our .info file, name gives out the name of our module and the description field tells a brief description of our module that will be displayed in the module listing page in Drupal.  Package is an optional field that tells Drupal in what category should our new module  appear in.


Step 3 -  Creating the .module file

This is the main script of our module. So it goes without saying that we will be working with it a lot.


Create a file named  computer_store with the extension of .module (computer_store.module) in your computer_store directory and enter following.







* Display help and module information


* @param section which section of the site we’re displaying help


* @return help text for section




function computer_store_help($section=”) {



$output = ”;


switch ($section) {


case “admin/help#computer_store”:


$output = ‘<p>’.  t(“Manages our computer storage and other details.”). ‘</p>’;






return $output;







Even though the above code is just the tip of the ice-burg it will give what we need – a start. What we have done basically in the above script is to add a hook_help to our module.


As I mentioned in an earlier article, hooks are implemented in Drupal to extend some known functionalities to modules and Drupal can call them when the suitable action is fired. In this case, the  hook_help will be called when a user goes to  Administrator->Help->Computer_store as displayed in P4: Figure 2 and P4: Figure 3 ( More on hook_help check http://api.drupal.org/api/function/hook_help/5). But before doing that we have to first install our module.



Step 4 -  Installing the module

 Goto Administrator->Site Building->Modules section and our new module should be listed there  in a category called “E-commerce” ! Even though we still have to build an install script, for the heck of it you can just install our new module and check how it goes.


If it installs correctly, you should be able to see it with the checkbox next to “computer_store” ticked in the Drupal modules page, as shown in the P4: Figure 1.


P4: Figure 2 – computer_store module listed in Drupal help page

P4: Figure 3 – computer_store help description


Next week

In this week article we have touched the basics of art of module creation in Drupal. In next week let’s go on adding more details such as a database table stricture to our module to bring it to some form of usefulness.

You can contact the author via laknath [at] vesess.com should you have any problems from implementing the above.


More Support Materials

Drupal API references – http://api.drupal.org/api/

Drupal coding standards – http://drupal.org/coding-standards

Writing secure code – http://drupal.org/writing-secure-code


Part 3 – File Structure


Once you get hang on the administration section of Drupal, the next obstacle could be understanding the file structure of the CMS. In fact, this is the norm for any common CMS available now a day. So let’s take a look at how the file structure of Drupal is made of.


Directory Structure

Figure 1 – Drupal Directory Structure



This folder is created by Drupal for user uploaded files such as user thumbnails for profiles. For the purpose of uploading files into this folder it requires write permissions or if not Drupal will warn you that this directory doesn’t have file write permissions and require enabling it in order to function file uploading.



This directory includes PHP include scripts that are required to run core activities of the CMS. In fact scripts that reside within this directory combined with core Drupal modules make the core of Drupal. Further this directory includes database wrappers for most common databases such as MySQL and PostgreSQL.


This directory includes miscellaneous scripts and images that are required for Drupal. Most noteworthy among these scripts are several javascripts such as Drupal.js and collapse.js that are needed for the admin section and other core functionalities. Also the JQuery library that comes with Drupal resides within this directory.



This directory is the usual place for core and other modules that will be used by Drupal. When you need to install a module (which can be browsed and downloaded freely from http://drupal.org/project/Modules) just extract the folder in to this directory and it should be shown in Drupal->Site Builing->Modules page.



This directory usually consists of various shell scripts that are required for various operations by the Drupal or functions like adding a cron tasks to crontab in a UNIX server.



The main purpose of this directory is to provide facilities to structure Drupal multi sites such as sites using common logins and modules, but with different databases and themes. But the default implementation includes only two directories that are essential for the functionality of Drupal. -


This directory usually holds only one PHP script (unless you are working on a Drupal multi site) with the name of settings.php which is imperative for a Drupal instance. This file is the default main configuration file for a given Drupal instance. Using this configuration file it’s possible to set the base URL, the database associated with and more settings of your Drupal instance.


This directory should be used to house modules that are required for a Drupal multi site meaning unlike installing modules in Modules directory, these common modules can be used by several Drupal sites.



This directory provides facilities to include different themes that can be managed from Drupal backend. Each Drupal theme should be housed in different folders within this directory with all necessary theme scripts, images, CSS and JS files. Once such a theme folder is extracted to this directory it will be shown in Drupal admin themes section and can be selected as the site’s default theme.


Essential Files

.htaccess File

In case you are using Apache server, this file can be used to handle the behavior of the server such as URL rewriting.etc using Apache directives.


Used as the entering point to the site and usually the script that’s looked for when you type just the domain (depending on your server configurations) of a site.


This file is used when running cron tasks to manage repetitive actions on the site (with a given time period to repeat) such as indexing a database.


This script is executed at the installation of the Drupal instance.


When a serious database change, module change or conflicts occur, Drupal can be fixed using updating the instance and update.php script is executed in such cases.


Robots.txt is used to manage the behaviour of search engines visiting the site in order to index it. You can define which directories that should be omitted from indexing which can be quite useful when managing search engines.


Something More

Even though through this article I have tried to give a gist of the default Drupal directory structure and essential files, remember this is only essentially true for Drupal 5 instances. Even then it could get complicated when coming to multi sites. Though there are no earth shattering differences between currently used Drupal versions, it’s not guaranteed to be the same and could vary a bit from version to version.  So as a rule of thumb, there’s no better way than searching and learning your self to widen your horizons when it comes to Drupal (or in most other cases with computers).


Part 2 – Administration

In my opinion the best place to start understanding the workings of Drupal – a CMS with a relatively longer learning curve – is understanding the admin section. Therefore in this article we’d be going through Drupal administration section and the organization.

Drupal admin section consists of 5 main categories divided according to the usage.

  1. Content Management
  2. Site Building
  3. Site configuration
  4. User Management
  5. Logs

Let’s take important sections of each category, briefly go through the functionality and see how they contribute to managing a Drupal site.

Figure 1 – Drupal main administration section


Content Management

Content is the most important aspect of a CMS and naturally there should be a comprehensive way to create and manage the content of a site. One of the main reasons that Drupal can be used as a all purpose CMS is Its thorough approach when it comes to handing content and managing customizable hierarchies through nodes and taxonomies which we will address later. For now let’s take most important sections of Drupal content managing category.


This is the starting point of creating a hierarchy of content in Drupal with vocabularies and terms. For example if there’s a need to create an archive of news articles regarding Sri Lanka and need to tag them according to the district, we can create a vocabulary named ‘Sri Lanka’ and use terms as tags to categorize articles according to the location it occurred.



This is the main hub of Drupal that’s dedicated to managing content, which includes filtering, editing, deleting and changing the status of articles. Through this section you can decided the status of the article as to whether it’s published or unpublished, sticky (glued to the front page) or not and allowed in the front page.

Figure 2 – Content management section


Site Building

There’s no use of telling that this sections is vital to managing a site because you can guess it from the title itself. If you haven’t already guessed, this is the section that allows you to configure all your basic building block materials in a Drupal site from the bottom up. There are four main sections to this category.


As mentioned in the earlier article, blocks are a basic type of building blocks in a Drupal site. You can use blocks as a visual kind of modules that can be added and moved to different areas of a site with a few clicks from this section. As a starting point you can use this section either to create blocks without using any modules (great for simple blocks) or manage existing blocks. You can then define where these blocks should appear with a list of defined url patterns or using PHP snippets. Also you can define the visibility (who can see this block?) of each of the block and some more other settings as well. Further, you’ll see drop down lists called “Region” and “Weight” for each block listed here. Region is the area that you’d like to make a block appear, such as the left side or right side bar of a site. You can define any number of these regions in your template.php and modularize the look of your site quite easily. The weight option is there to define in what order your block should appear. Going with the flow of the nature, lighter the weight of the block becomes, higher it appears and vise versa.

Figure 3 – Drupal modules section


Menus are there in Drupal to help navigate through the site. But the specialty is that you can arrange them in to a complex hierarchy through this section. Further it allows to Create, edit and delete menu links.


Modules are the building blocks of Drupal from its core to every extended feature and it goes without saying how important this section is. You can keep track of module dependencies, install and remove them through this section.


Drupal themes are the basic and main building block of the visual representation of a Drupal site. In fact Drupal theme engine is so flexible to do almost any of your biddings that it has largely contributed to Drupal’s success as an all-in-one-go solution. Through this section we are given the chance to configure the current theme, choose enabled themes and theme materials such as the logo, favicon, site name and mission statement for each theme listed there.

Figure 4 – Drupal themes section
Site Configuration

This is the set of Drupal pages that allows you to configure the behavior of a [existing] Drupal site. There are some general sections built in here, but other parts are added by modules you plug in later. In fact if you someday write a Drupal module and decided to add an administrator page, it will be added to this section. Let’s go through some common pages built in with the default Drupal deployment.

Administrator theme

This page allows you to select your administrator theme from the collection of themes you have in your themes section.

Figure 5 – A customized Drupal admin theme used in Hotelotravel.com


This section is vital when you have a large site in your hands where you need to optimize Drupal. In such a case you can save a considerable chunk of bandwidth by enabling caching and CSS compression to reduce the number of http requests you send.

Site maintenance

This allows you to make a site off-line to do your site’s maintenance tasks. You can also define your own off-line template to make it look cool even when you are not functioning.


User Management

User management is a large part of any CMS and as usual Drupal has a great way to handle a site’s users with maximum flexibility.


This is the main user management section and it goes without saying that it’s pretty important. You can edit user profiles, filter or delete them and manage user roles through this section.


Role is Drupal way of delegating the responsibility to a selected group of users. By defining a role you create sort of a user group (even though it may have no users) with certain privileges. Later when you create users or new users are signed up, they can be added to these roles you have created.



This section is important when you manage a large site and come up with some error. But even when you are running without a hitch, it’s important to manage things like your cron tasks (if you have tasks that you need to perform regularly such as syncing your RSS aggregator you will need cron) for better functioning of the site.

Status report

This section contributes to healthy functioning of a Drupal site. You can run your cron tasks manually through this section if they are not automated. Also you can get info about your Drupal deployment such as whether your file system is writable, MySQL database, PHP and the server environment.

I guess this covers the basic Drupal admin tasks. But always keep in mind that “Trial and error” method is the best way of learning things and for Drupal it’s no exception.

Figure 6 – Drupal status report section



In the world of IT convenience is a major factor that drives the progress. Content Management Systems (CMS) such as Drupal, Joomla, WordPress or MODx are prime examples for this. Throughout this article series we’d be looking at how to use the all purpose CMS-Drupal  to our advantage.


Logos from WordPress, Joomla and Drupal


By the definition CMS is a computer application used to create, edit and manage various kinds of digital medial and text. There are many variations with CMSs but some common characteristics such as login and user management facilities can be identified as well. Most of the times CMSs are created with the intention of a particular audience or a set of tasks. For example the main audience of WordPress is the crowd of blogsphere and it has become the de facto CMS for a simple (or may be not that simple with recent upgrades) blog now. But few CMSs such as Drupal and Joomla are designed in a way that suits all purpose and all audiences. Also CMSs can be futher categorized based on their commercial background. Drupal as well as Joomla and WordPress are several Open-Source content management systems that are currently in wide use. There are also many popular commercial CMS platforms such as ExpressionEngine that provide their service at a cost.

As most of successful open source projects, the vast community that’s around Drupal is what gives it the power to be a leading CMS in the open source arena. As of recent stats it has a member base of more than 350,000 and a developer base of more than 2000. According to Drupal download stats, within the year May 2007 to April 2008 alone it has recorded more 1.4 million downloads which is a 125% growth from year 2007. This exponential growth also means the rapid growth of the community as a whole. Among few notable sites that have used Drupal as its CMS platform are NASA, FedEx, MTV UK and Ubuntu(many other popular Drupal based sites are listed here at http://buytaert.net/tag/drupal-sites). Also Drupal won the awards for best PHP based CMS and Overall Open Source CMS which were the most tightly contested categories at CMS awards 2008.


Mementos from CMS Awards ’08

The Drupal project started as a message board by Dries Buytaert and became an open source project under GNU Public License (GPL). Dries wanted first to name the site as ‘Dorp’ which in Dutch means village which in turn meant to refer the community around it but later it was changed to Drupal because it sounded better. Drupal is an English rendering of the Dutch word ‘Druppel’ which gives the meaning ‘drop’ and the current Drupal logo is depicting it as a water drop.

So that now we have taken the first steps toward Drupal let’s get down to real work.

The ways of Drupal

Drupal is not just a Content Management System, but also a modeler frame work. The invincibility of Drupal that makes it a possible solution to all situations comes from the way it’s organized. This modular framework allows it to be extended and to add new features through modules or change the  complete look and feel through themes without a drop of sweat.

When we consider the structure of a Drupal site, we can break it into two major parts which are,

  1. Modules
  2. Themes

So now let’s skim through modules and themes of Drupal with the intent of diving deeply into them at a later time.


The power of modules

Most the functionality of Drupal is rendered through its modules set. There is a set of core modules that comes with Drupal that handle all the basic tasks of the CMS such as login and user management, error logging and other essential system tasks. Other than these core module, there’s also a set of optional core modules that comes with the installation for various tasks such as RSS aggregation, handling user profiles and managing user comments though unlike core modules they are not mandatory for running the system. For extra functionality users can download suitable modules freely from the vast modules repository at http://drupal.org/project/Modulesor create your own modules to achieve the desired functionality (which we will look thoroughly at a later time).

Hooks can be considered as the most distinctive characteristic of Drupal module architecture. The concept of hooks is mainly to allow modules to interact with the Drupal core. To extend Drupal, a module needs simply to implement the appropriate hook from the defined set of hooks (to get the full list of hooks for Drupal 5 see http://api.drupal.org/api/group/hooks/5). When Drupal wishes to allow intervention from modules, it determines which modules implement a hook and call that hook in all enabled modules that implement it.

Blocks are also another major component of modules that worthy taking a peek into. Even though it’s not mandatory for a module to have a block, most of modules that represent something visually have blocks. Blocks are separated, customizable areas of the web site that can be moved to various positions of the site with just a few clicks from the back end, which in turn makes it so unbelievably flexible and customizable. For example the login box in Drupal is a block that’s implemented in the core User module which provides basic login functionality. Even though by default it’s in the side bar of a page, with just a small change from the back end to the position of the block, it can be moved to any position of the page (or any where a region -a defined boundary in the site that a block can be displayed- is defined). With each module having the capability of creating as much as blocks necessary, it makes modules even more flexible and powerful.


Drupal module administration page


The beauty of Drupal themes

A Drupal ‘theme’ is a collection of files that makes the presentation layer of the site or in other words defines the “look and feel” of the site. It contains the underlying hierarchical page structure which decides the order of how a page should be properly overlapped and rendered, the the cascading style sheets (CSS) files that controls the presentation and even javascript files that are used for dynamic page content.

The best and most noticeable feature of a Drupal theme is it’s abstraction and hierarchical order. The order of a theme usually comes in the bottom-up incrementing way such that it can control the presentation of almost everything of the site. For example the default presentation of a button that’s defined in a block can be easily changed through overriding the appropriate default element template in your theme. Now if you want to change the look of this block, it can be done by defining a block template for that particular block. Then if you still need to change the look of all blocks as a whole you can override the default block template. But this hierarchy is not only limited to visible regions of the site such as blocks; it can also separately customize deferent content types of the site. Also you can define a template for the front page and another for repeating mundane middle pages. Now you might see what I meant when you can change almost everything of a site with the help of Drupal theming hierarchy.

As a side note. a basic knowledge of PHP could be a help for some tasks, but even without it you will still be able to do a good theme if your theme is not much complicated and does not override the default behaviour. Drupal comes with a few built in themes and for more themes you can use the repository at http://drupal.org/project/Themes to see any matching theme to your requirements or at least a close resemblance that can be customized without building from the scratch.



A word about versioning

A new user to Drupal can get bit dazzled by various Drupal versions out there. There are still 4 versions going around ranging from Drupal version 4 to 7. Even though it has been over a year since Drupal 6 has been released, Drupal 5 is still seems at the forefront with the compatibility of  modules. Further, as of now Drupa 4 is on it’s way to getting extinct while Drupal 7 is still too unstable and not supported by other modules for any practical purpose.

To get any of above Drupal versions use the URL http://drupal.org/project/Drupal+project.


Enough Chit-Chat

So now we know the basics and the background of Drupal let’s setup a Drupal site in your localhost. For this you only require a web server (apache, IIS .etc) with PHP enabled and also a Database management system such as MySQL or PostgreSQL installed.

Getting a Drupal site set up is easier than a piece of cake. Here are the simple steps that you have to follow.

  1. Decide which Drupal version you are going to use and download it from above address.
  2. Unzip the download package and put it in your web server document root.
  3. Create a new database (you can use a tool like phpMyAdmin or just terminal for this) and enter the database name and database logins to Drupal installation page
  4. Click next and Drupal will set up itself.
  5. Now you can goto the Drupal administrator account for the first time and add logins to your super administrator account and submit.
  6. That’s all, you are ready. It wasn’t hard, was it ?


Like to give a hand ?

Drupal community has created and maintained this wonderful and unbelievably useful CMS with their hard working. So while you are using this amazing CMS, do you feel like giving a hand ? You won’t have to be able to code; You can contribute by writing some documentation or testing and reporting few bugs in the plethora of modules available there. Also you can join live discussions at IRC #drupal, #drupal-themes, #drupal-dev or #drupal-support at Freenode for more deeper subjects. All your support will be enough to improve at least a tiny bit of the project which in turn will help many others in the long run.