- Talk notes from the BAD Monday meetup

By Guy Shneerson of Blue-Bag Ltd (www.blue-bag.com)    Guy@blue-bag.com

Notes form my presentation at the Brighton Area Drupal meetup (BAD monday) on Monday 18/04/2011 at the Skiff

Thanks to Steve for organising the evening and to all that attended

Overview

A basic introduction to the Drupal architecture and the elements that make up almost every Drupal site from the simplest to the most complex. I will cover the range of elements that make up a Drupal site from the core files through user configured blocks, custom code and the rich array of 3rd party modules and themes. Each of these could be the topic of a talk in its own right and therefore I won’t go into much details about each. I want to cover the Drupal ‘environment’ and how each elements works within it.

Part one: Drupal architecture

What is Drupal?

A free and open source content management system (CMS) and Content Management framework (CMF) written in PHP (source wikipedia)

One of the most important points about this statement is that Drupal is not simply a Web Content Management System (WCMS) but is a content management framework that enables you to deliver a much richer set of ‘content’ than other ‘blogging’ CMS systems (such as Wordpress, Joomla etc). Drupal has from its beginning been based on an approach of abstraction and isolation/integration concepts - making the technology more flexible extensible and future proof.
It isn’t the purpose of this presentation to go over the ‘selling-points’ of Drupal - for that you can see http://www.digett.com/2009/01/22/drupal-selling-points.

What makes a Drupal site:

• Database: typically MySQL (but more support is growing for other DBMS thanks to the database abstraction layer);
• PHP code:  (module files .module .inc files) configuration;
• Template files (HTML mark-up of Drupal content - referred to as theming)
• Javascript and JS Frameworks (JQuery) for client side functionality;
• CSS - Styling;
• Files: Images and other media.

Configuration: Both Drupal and code modules use configuration files to some extent but the majority of configurations is stored in the database.

The modular approach

Drupal provides a core set of functionality (modules) and designs (templates and themes) that can be extended by installing additional modules and themes.
It is also possible to create custom modules and templates to implement specific ‘bespoke’ functionality or look and feel that are not available from the Drupal community.  However with over 7000 3rd Party modules available covering a wide range of functionality it is always best to assume that ‘there is a module for that!’ before starting your own from scratch.
Many modules also integrate with server task scheduling (CRON)  allowing for scheduled operations on the site.

There are three important and unique characteristics of the Drupal approach:

• Standards – Coding /  Testing / VC (promotes security and robustness)
• Interaction – With other modules (most of the popular modules interact and do not provide stand alone functionality)
• Cooperation (minimise duplication of modules try and cooperate on projects and not create competing approaches if possible)     

More and more Drupal developers are realising that most of the code they write is “Glue Code”: Tying together existing functionality.
There are very few modules that duplicate functionality and whereas within the Wordpress community you may see a lot of reviews of plugins that provide functionality ‘X’, in Drupal there is generally one module for a specific functionality to which many people contribute. Also modules often work in partnership with other modules rather than trying to be an all singing and dancing solution. These means that configuring modules is more of a task than choosing them.

Development of a Drupal site

The two methods of developing a site:

User Interface (UI) – Configure the environment;
API – Develop any bespoke functionality
Key concepts: Separation of interface and api

Part two: The Drupal engine

The request roadmap

(A rough breakdown as Drupal modular role based access can blur the lines)
Admin – configure & compile the environment.
Authenticated Users – interact with the environment and content
Non authenticated users - Voyeur  

Drupal uses ‘registries’ to determine the nature of modules and themes enabled for a site. It does this by scanning the file system for specific code signatures or ‘hooks’. These are then ‘noted’ within a cached registry that can be referred to by each request to prepare the environment required to fulfill the request.
This process is triggered by the use of the Administration interface (and in cases through the task scheduler) so that the work required is prepared before visitors to the site request pages.   
 

HTTP first stop - The Core

When a request is made to a Drupal site and the web server has passed the request to Drupal the first phase of activity is the Bootstrap. This loads the functional Drupal environment, referring to the prebuilt registry of variables and function references  and determines the ‘path’ of the request and what is required to fulfil it.
Every typical call to a Drupal  site goes through Index.php. Rewrite rules in the web server (typically in the .htaccess file in the site root) pass the path of the request as a query string to index.php. This query string parameter is used to determine what is required to fulfil the request.
So:
http://example.com/homepage = http://example.com/index.php?q=/homepage = http://example.com/index.php?q=node/1

Index.php

• Initilize: Session /  Database / Variables / Caching / Localization

• Menu router: Drupal menu system and URL route - What is required for the request;
• Hooks: activation of modular functionality;
• Theme engine.

Process

• Modules load and initialize the enabled modules;
• Menu router – activates functionality (registered hooks)
• Theme engine – theme the page (triggering all elements hooked to it).  

Modules register both functionality and output formatting (theming) using hooks that are triggered by the menu router.

Part three: Extending Drupal functionality using modules

Drupal Core modules

Every Drupal installation has a set of core functionality:

• System: An integral part of core.
• Node: The basic content used on a Drupal site (a data object) nodes can be created for different type of content.
  
  Two types of content types (node types) are enabled by default: Story and Page
  Nodes can be a page, story or extended to support Blog entry, Articles, entities such as people, organisations, etc.
  Nodes provide basic functionality and fields that can be extended by other modules as we will see later.
  Nodes are managed by the content admin interface and inline editing for people with the right permissions.
  
• Blocks: Those can be blocks of static content/HTML embedded PHP code or generated dynamically by modules, and positioned on pages using regions (allocated areas of a Drupal page rendered by the theme engine).
  The blocks admin interface allows the creation and management of blocks. alternative methods of managing blocks are in two very popular modules: panels and context.
• User: The user registration and login system. The user is based on a highly granular role/permission based system.
• Filter: Handles the filtering of content and its caching in preparation for display.

Optional Drupal core modules

There is a rich set of optional modules that come with every Drupal installation and can be enabled if required. Key examples are:

• Menu: admin interface to menus;
• Path: Allows users to rename URLs.
• Search: the default search engine (uses the main Drupal database) alternative search systems can be used like Solr;
• Taxonomy: a taxonomy and vocabulary (free tagging) used for the categorization of content;
• Book: Another approach to hierarchical data (taxonomy) using the menu system to create a ‘paged’ set of nodes akin to pages and chapters of a book.
• Comment: Allows users to comment on and discuss published content

Some other worth noting: Syslog / PHP filter / Trigger / contact / profile / Poll / Content Translation

Contributed Drupal modules

Contributed modules are developed by the community and are maintained separately from the core code. There are over 7000 contributed modules - I will cover the more generic ones; ones that are typically/commonly  enabled on most sites.

Drupal Top 20 installed modules

(source http://drupal.org/project/modules)

(to get to a module use the pattern http://drupal.org/project/[projectname] - e.g. http://drupal.org/project/views)
Not all sites announce their use of a module (requires Update Status module to be enabled)

• CCK / Fields: CCK (content construction kit) is a contributed module for 6 that has been integrated into the core of 7 as fields.
  
  It allows the extension of the basic node type by adding a variety of fields.  In Drupal 7 it allows the extension of taxonomy and users.
  
  While CCK/Fields provides a number of field types it supports plug-in modules to extend this by adding additional field types (e.g. Date,Image Field, File Field, Currency etc)
• Views: (and ChaosTools) without views we are nothing and you can quote me on that
  Views is a visual query builder for Drupal that enables the creation of queries (sql) and the output (themed results) using a visual interface. These can then be used to populate blocks or whole oages with content.
  It allows you to do things like:
  Give me a list of all nodes that are of type employee that belong to the accounts department.
  Provide a report of title of blog posts edited by guy sorted by most recent etc.
  
  Views are important for presentation navigation and reporting of content but this is just the tip of the iceberg of what can be done with them.
• Wysiwyg: Enables and simplifies the use of client-side HTML editors. It simplifies the installation and integration of the editor of your choice like TinyMCE & CKEditor.
• Pathauto:  (and tokens) allows for the automatic creation of URL aliases for your content;
• Administration Menu - Theme-independent administration menu at the top of the page fast access to all admin tasks
• ImageField, FileField and ImageCache: add image support for CCK (a part of core of 7)
• Context, Display suite & Panels:  While all three are not essential as you can achieve the same results without them, they all provide powerful system for the organisation and display of content, and you can tell a lot about a developer by his choice and use of this modules (I am a context and DS man myself).  
• Taxonomy Manager: Tool for administrating taxonomy terms.

SEO Utility modules

• Google Analytics Integrates your site with Google analytics
• Nodewords (Metatags): Allows users to add meta tags, e.g. keywords or description. This module doesn't actually implement any meta tags, but requires other modules to implement them.
• Page Title: Enhanced control over the page title (in the <head> tag).
• Global Redirect: Searches for an alias of the current URL and 301 redirects if found. Stops duplicate content arising when path module is enabled.
• Path Redirect: Redirect users from one URL to another.

Development utilities

• Drush: Command line interface to Drupal
• Devel: Access variables and other developer tools to aid in the development of a site
• Coder: Auding facilioty to find issues with custom code
• Util: Host of plugins to manage your drupal installation
• Drupad / Drupal Notifier:  iPhone utilities for remote management of a site

Other useful Drupal modules:

• Mollom: Anti spam control for comments and forms, A CAPTCHA challenge-response system
• Date & Calender
• Webform - A webform node type to your Drupal site
• Backup & Migrate
• Lightbox2 / Thickbox
• Taxonomy Menu – powerful taxonomy admin interface