A brief overview of Drupal 7
By Robin Isard, Systems Librarian
Algoma University
What I'm going to look at

Overview of Drupal 7

The module system

How Drupal manages your data

Case study – 2 years working with Drupal
What is drupal?

Content Management System



Becoming more of a Content Management
Framework
Created by Dries Buytaert, a Belgian computer
science student in 1998
3 major releases since then

Current major release is Drupal 7

As of 2011 approximately 630,000 subscribed users

“A drop”
Architectural Overview

Essentially a LAMP stack

Modular


Core

Contributed

Custom

Themes
Business logic intensive
Core

Core modules

Blogs

Comments

Aggregator (RDF,
RSS, Atom feeds)

Hierarchical ordering
of content

Tracking system

Statistics

Forums

OpenID login

Polls

Logging

Taxonomy (tagging)

Theming system

Menu customization

Update manager

Trigger system
Drupal community
Contributed modules

Functionality and themes

9947 modules total

3929 compatible with Drupal 7

“Content”: 551

“File Management”: 90

“Administration”: 343

“Themes”: 298
IMCE
How modules work

A collection of php files designed to implement
some find of functionality

/sites/default/modules

mymod.info

mymod.install

mymod.module
.info
name = Administration menu
description = "Provides a dropdown menu to most administrative
tasks and other common destinations (to users with the proper
permissions)."
package = Administration
; Purposively added for feature development.
version = 7.x-3.x-dev
core = 7.x
project = admin_menu
/**
.install
* @file
* Install, update, and uninstall functions for the admin menu module.
*/
/**
* Implements hook_schema().
*/
function admin_menu_schema() {
$schema['cache_admin_menu'] = drupal_get_schema_unprocessed('system',
'cache');
$schema['cache_admin_menu']['description'] = 'Cache table for Administration
menu to store client-side caching hashes.';
return $schema;
}
.module

Hook system

Php function

Defined input and output

Allows you to implement a certain behavior at a
certain point in drupal core
Hooks


<moudle_name>_<hook_name>()

hook_user_load()

mymod_user_load()
342 available hooks

hook_comment_load

hook_cron

hook_css_alter

hook_field_validate
Example
/**
* Implements hook_help().
*/
function admin_menu_help($path, $arg) {
switch ($path) {
case 'admin/settings/admin_menu':
return t('The administration menu module provides a dropdown
menu arranged for one- or two-click access to most administrative
Tasks … the menu.');
case 'admin/help#admin_menu':
$output = '';
$output .= '<p>' . t('The administration menu module provides a dropdown
menu arranged for one- or two-click ....');
APIs

Module system (Drupal hooks)

Database abstraction layer (Schema API)

Menu system

Form generation

File upload system

Field API

Search system

Node access system

Theme system
Data access and storage
Data management

By default a LAMP stack


Drupal 7 has a rewritten database abstraction
layer



Other database options available with more or less
support
PostgreSQL now a first class member of the
community
MongoDB
Essentially uses Object-relational mapping
APIs

Entity (core)


Entity API
Schema API
Important data management
concepts


Entities

Users

Taxonomy terms

Comments

Nodes
Fields

Entity + Fields = Bundles
Bundle - Example

news_item (a node entity)
+

Date (field)

Subject (field)
=

“news_item bundle”
Key entity hooks

hook_entity_info()


hook_schema()


Entity (core)
Schema API
Entity API

entity_create()

entity_save()

entity_delete()

entity_view()

entity_access().
hook_entity_info()
function user_entity_info() {
$return = array(
'user' => array(
'label' => t('User'),
'controller class' => 'UserController',
'base table' => 'users',
'uri callback' => 'user_uri',
'label callback' => 'format_username',
'fieldable' => TRUE,
'entity keys' => array(
'id' => 'uid',
),
'
hook_schema()
function user_schema() {
$schema['authmap'] = array(
'description' => 'Stores distributed authentication mapping.',
'fields' => array(
'aid' => array(
'description' => 'Primary Key: Unique authmap ID.',
'type' => 'serial',
'unsigned' => TRUE,
'not null' => TRUE,
),
'uid' => array(
'type' => 'int',
'not null' => TRUE,
'default' => 0,
'description' => "User's {users}.uid.",
hook_schema()

Supports primary and foreign keys

Supports indexes

Field lengths


Precision
Signed / unsigned
Data storage example
Data storage example
public | node
| table |
public | field_data_field_db_access_link
| table |
public | field_data_field_db_build_name
| table |
public | field_data_field_db_description
| table |
public | field_data_field_db_ezp_note
| table |
public | field_data_field_db_ezp_test
| table |
public | field_data_field_db_sfx_name
| table |
public | field_data_field_db_url
| table |
Data storage example
TABLE: node
nid
vid
type
| 164
| 164
| db
language
| und
title
| Women Writers' Project
uid
|1
status
|1
created
| 1317243764
changed
| 1332779771
comment
|1
promote
|0
sticky
|0
tnid
|0
translate
|0
TABLE: field_data_field_db_url
entity_type
| node
bundle
| db
deleted
|0
entity_id
| 164
revision_id
| 164
language
| und
delta
|0
field_db_url_value | http://....
field_db_url_format |
Viewing your data


Views module

Still a contributed module

Essentially a report writer

Complicated
Database API
An example: Algoma University's Archive
Algoma University Archive

Over 25,000 images and documents

3 TB of data on scattered hard drives

Most of the data important for legal purposes

Index housed in InMagic-DBtextworks

“Relational like”

ASP driven

No social media aspects

No means to display the content in an engaging
way
Questions we asked about a new
CMS

Service integration

Is there documentation?

Is there an API?
Does it support data exchange protocols?



JSON
XML
RDP
Questions we asked about a new
CMS

Data access and storage

How does it store data?

Does it have a CRUD layer?

Can I get my data out of it in standard formats?



CSV
XML
What options are there for non-sql data?
Migration

2010 project started to update the archive

We chose Drupal because

It seemed to answer the questions listed above

of it's very large user community

recommendations from peers


it's ability to integrate with enterprise technologies
like Fedora Commons and Solr
It's social media abilities
Phase 1

Get the data out of InMagic and into Drupal

Took nearly 4 months

Process

Dump the data out of InMagic as CSV files

Import into PostgreSQL

Use SQL to clean up and format the data

Use “migration module” to import the cleaned up
tables into Drupal
Phase 2


Use Drupal's extensibility to ability to meet
archivist needs for the archive
Problems with contirb

Postgres

Bad code

Malfunctioning modules

Dates

Unix time stamp no good for archives
Phase 3 – in planning

Migrate to drupal 7

Needs to be done


No back-porting
Drupal is now smarter about databases – which is a
problem
Lessons learned - modules

Drupal runs the show

Always interact with Drupal via a module

Stay as close to core as possible

Is this the best possible module for the job?

Put time into choosing modules


When was the last commit?

Do you understand the code yourself?

Is there a plan to upgrade it?
Read the code for you modules

You should be able to fix it yourself
Lessons learned - database


Drupal doesn't really like relational databases
Do you know what a given module will do to the
DB?

Categories module

Does it use MySQL specific statements?

Use Fields and Views as much as possible

Always interact with the DB via a module
The possibilities

Database layer can be rewritten



All kinds of data stores theoretically possible
Can be conceptualized as simply a user interface
for different kinds of data stores
Discovery

Solr integration

Islandora

Web services