Drupal Training

1. Session 1 Introduction to Drupal Drupal Training Justin Klein Keane <jukeane@sas.upenn.edu>

2. Justin Klein Keane <jukeane@sas.upenn.edu> Overview • What is Drupal? • Building blocks of Drupal • Drupal terminology • How Drupal works

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. Justin Klein Keane <jukeane@sas.upenn.edu> Node Openid Path Php Ping Poll Profile Search Statistics Syslog System Taxonomy Throttle Tracker, translation, trigger, update, upload and user Built in Modules • Aggregator • Block • Blog • Blogapi • Book • Color • Comment • Contact • Dblog • Filter • Forum • Help • Locale • menu

18. 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”

19. 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

20. 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

21. 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

22. 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

23. 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”)

24. 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

25. 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

26. 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

27. 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

28. 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

29. Justin Klein Keane <jukeane@sas.upenn.edu> Default Drupal is Pretty Useless

30. 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

31. 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