Drupal Training
Session 1
Introduction to Drupal
Justin Klein Keane
<jukeane@sas.upenn.edu>
Overview
●
What is Drupal?
●
Building blocks of Drupal
●
Drupal terminology
●
How Drupal works
Justin Klein Keane
<jukeane@sas.upenn.edu>
What is Drupal
●
Open source content management system
●
What is a CMS?
●
Drupal is actually much more than a CMS
–
Web application framework
Justin Klein Keane
<jukeane@sas.upenn.edu>
PHP
●
Drupal is written in PHP
●
Web application scripting language
●
Open source language sponsored by Zend
●
PHP is actually written in C
●
Easy to learn
●
Great for rapid application development
●
One of the more popular languages for web
applications
Justin Klein Keane
<jukeane@sas.upenn.edu>
How PHP Works
●
●
●
●
PHP is run by the web server
PHP code embedded in web pages is compiled
and interpreted when the page is requested
Uncompiled code means portability and rapid
refactoring
PHP is truly dynamic
–
●
Even variable names can be dynamic
Code can include other scripts or libraries
Justin Klein Keane
<jukeane@sas.upenn.edu>
Data Persistence
●
●
Like most web applications Drupal needs to
store data
Data is in a database (MySQL)
–
Database means content changes happen in
the database rather than in code or on files
–
Makes for easy portability and backup
–
Access via code, or directly at command line
–
SQL is a standard, popular, well understood
language
Justin Klein Keane
<jukeane@sas.upenn.edu>
Drupal Hierarchy
●
Drupal uses dynamic includes to load code
●
What happens when there are conflicts?
–
●
Last loaded code is the one that runs
Drupal uses this to allow developers and users
to “extend” Drupal
Justin Klein Keane
<jukeane@sas.upenn.edu>
Composition of Drupal
●
Drupal includes a common set of files used to
“bootstrap” Drupal
–
●
Set up database connections, provide
authentication, present output, etc.
Drupal has additional modules
–
These are dynamically included depending on
configuration
–
33 modules are included in the Drupal core
Justin Klein Keane
<jukeane@sas.upenn.edu>
Running Drupal
●
●
Every Drupal request goes to index.php, even if
the URL looks like a different location
Index.php does bootstrapping:
–
checks database for enabled modules
–
loads modules that are appropriate
–
checks permissions
–
queries database for content
–
applies theme
–
renders the page
Justin Klein Keane
<jukeane@sas.upenn.edu>
When things go bad
●
When Drupal encounters a PHP fatal error:
–
●
White screen of death
What has happened:
–
PHP hit an error that forced a stop to
compilation
–
PHP logs the error in the web server logs
–
Potentially Drupal logs the error in the Drupal
watchdog table
–
Execution dies silently without output
Justin Klein Keane
<jukeane@sas.upenn.edu>
Drupal filesystem structure
/includes
- Drupal core PHP files
/misc
- Various image and js files
/modules
- Core modules
/profiles
- Profile settings (own tree)
/scripts
- Maintenance non-web scripts
/sites
- Site definitions
/themes
- Core themes
Justin Klein Keane
<jukeane@sas.upenn.edu>
Top Level Files
●
Several critical php files:
cron.php
- web interface for scheduled tasks
index.php
- everything flows through index.php
install.php
- installation file (remove)
update.php
- update install (for new modules)
xmlrpc.php
- provide remote procedures (opt.)
●
Various other text files
Justin Klein Keane
<jukeane@sas.upenn.edu>
How to install Drupal
●
You need a database and a web server with
PHP already running
●
Create a database for the Drupal site
●
Download the Drupal code from Drupal.org
●
Point web browser and Drupal root and the rest
is automated
Justin Klein Keane
<jukeane@sas.upenn.edu>
Drupal terminology
●
Drupal uses a lot of words that have very
specific meaning:
–
Module
–
Theme
–
Block
–
Node
–
Menu
Justin Klein Keane
<jukeane@sas.upenn.edu>
Modules
●
●
Modules can be installed in a number of
locations
–
/modules
–
/sites/all/modules
–
/sites/default/modules
–
/profiles/profileName/modules
Modules should be installed in:
–
/sites/all/modules
Justin Klein Keane
<jukeane@sas.upenn.edu>
What is a “module”
●
Modular piece of code that extends Drupal
●
Uses the Drupal API
–
Just a set of functions defined in the Drupal
core (or other modules)
●
Provide drop in functionality
●
Can be enabled/disabled (in the database)
●
Provide additional functionality without altering
the Drupal core
Justin Klein Keane
<jukeane@sas.upenn.edu>
Built in Modules
●
Aggregator
Node
●
Block
Openid
●
Blog
Path
●
Blogapi
Php
●
Book
Ping
●
Color
Poll
●
Comment
Profile
●
Contact
Search
●
Dblog
Statistics
●
Filter
Syslog
●
Forum
System
●
Help
Taxonomy
●
Locale
Throttle
●
menu
Tracker, translation, trigger, update, upload and user
Justin Klein Keane
<jukeane@sas.upenn.edu>
Look and Feel
●
Drupal takes a similar approach to display
●
Display is a separate area of Drupal
●
●
Many components of Drupal are defined in the
“theme”
Themes are comprised of HTML, CSS, PHP
and imagery
●
Themes utilize the same hierarchy as modules
●
Theme files are called “templates”
Justin Klein Keane
<jukeane@sas.upenn.edu>
Advantage of Themes
●
●
●
●
Themes follow a convention (standardization)
Can easily be swapped out to quickly change or
upgrade the look of a site
Useful because theme developers need not
necessarily be Drupal developers (or PHP
programmers)
Can provide powerful filters to screen output in
Drupal
Justin Klein Keane
<jukeane@sas.upenn.edu>
Blocks
●
●
●
●
●
Blocks are pieces of content placed in regions
of Drupal pages
Blocks are arbitrary pieces of content
Usually the stuff that appears in sidebar, header
and footer content
Blocks can be content, forms, special lists,
polls, or arbitrary HTML
Themes define regions for blocks
Justin Klein Keane
<jukeane@sas.upenn.edu>
Nodes
●
●
●
●
Drupal organizes most content around the
concept of a “node”
Nodes are just pieces of content
Only a few things aren't nodes – users, groups,
modules, and themes being the main ones
Other stuff, from calendar events, to RSS feed
items, to page content is a node
Justin Klein Keane
<jukeane@sas.upenn.edu>
How Nodes Work
●
●
●
●
Nodes support versioning
As a result node content is stored in the
node_revisions table
The Drupal “node” table only stores metadata
about nodes
Nodes can have various modules applied to
them to adjust input and output handling
Justin Klein Keane
<jukeane@sas.upenn.edu>
Organizing Nodes
●
●
●
●
●
There are all sorts of nodes, how do we keep them
organized?
Drupal supports a categorization of nodes that allows for
various node “definitions”
Content types allow Drupal users to define various fields
for different types of nodes
For instance, one node might include a URL, another a
title
Using “fields” specific to node types allows sorting and
display (rather than having the data stuck in a node
“body”)
Justin Klein Keane
<jukeane@sas.upenn.edu>
Content Types
●
“Page” and “Story” are two default content types
●
The titles are arbitrary
●
●
●
Content types define input fields and how the
content is displayed
New content types can easily be created
Content type creation should follow careful
consideration of site architecture and purpose
Justin Klein Keane
<jukeane@sas.upenn.edu>
Taxonomy
●
Taxonomy is another way to organize content
●
Taxonomy are “tags” that are applied to content
●
“Vocabularies” set up as taxonomies
●
Vocabularies then contain terms
●
●
Taxonomies can be extended and used for
various rules in the Drupal back end
Taxonomy can also be used for display
purposes
Justin Klein Keane
<jukeane@sas.upenn.edu>
Menus
●
Drupal menu system is also fairly arbitrary
●
Display and positioning is controlled by themes
●
Three default menus:
–
Navigation
–
Primary links
–
Secondary links
Justin Klein Keane
<jukeane@sas.upenn.edu>
Users and Groups
●
Drupal allows users to create accounts
●
Users are assigned to groups
●
By default two groups are defined in Drupal
–
Authenticated User
–
Anonymous User
Justin Klein Keane
<jukeane@sas.upenn.edu>
Permissions
●
●
●
●
●
Drupal utilizes a Role Based Access Control
(RBAC) system
Users are assigned to roles, roles receive
permissions
Permissions are set through the Drupal
administrative interface
Uid 1 user (created during install) has all
permissions
When in doubt: it's a permissions issue
Justin Klein Keane
<jukeane@sas.upenn.edu>
Default Drupal is Pretty Useless
Justin Klein Keane
<jukeane@sas.upenn.edu>
Got Drupal, now what?
●
●
●
●
●
Drupal out of the box doesn't look like much
Drupal is extremely flexible but requires a lot of
configuration
Changing Drupal after deployment is a pain, so
you must plan carefully
Drupal is a framework that doesn't make
assumptions about use cases
Drupal requires lots of tweaks to enable
functionality the way you want it
Justin Klein Keane
<jukeane@sas.upenn.edu>
For next time:
●
A walk through of Drupal installation
●
Installing and enabling modules
●
A walk through of module cod
Justin Klein Keane
<jukeane@sas.upenn.edu>