1 / 39

A brief overview of Drupal 7

Dive into Drupal 7 with insights on modules, data management, and a case study after 2 years of usage. Explore Drupals roots, community, APIs, data concepts, and management techniques.

Download Presentation

A brief overview of Drupal 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A brief overview of Drupal 7 By Robin Isard, Systems Librarian Algoma University

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

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

  4. Architectural Overview • Essentially a LAMP stack • Modular • Core • Contributed • Custom • Themes • Business logic intensive

  5. Hierarchical ordering of content Tracking system Statistics OpenID login Logging Theming system Update manager Trigger system Core • Core modules • Blogs • Comments • Aggregator (RDF, RSS, Atom feeds) • Forums • Polls • Taxonomy (tagging) • Menu customization

  6. Drupal community

  7. Contributed modules • Functionality and themes • 9947 modules total • 3929 compatible with Drupal 7 • “Content”: 551 • “File Management”: 90 • “Administration”: 343 • “Themes”: 298

  8. IMCE

  9. How modules work • A collection of php files designed to implement some find of functionality • /sites/default/modules • mymod.info • mymod.install • mymod.module

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

  11. .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; • }

  12. .module • Hook system • Php function • Defined input and output • Allows you to implement a certain behavior at a certain point in drupal core

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

  14. 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 ....');

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

  16. Data access and storage

  17. Data management • By default a LAMP stack • Other database options available with more or less support • Drupal 7 has a rewritten database abstraction layer • PostgreSQL now a first class member of the community • MongoDB • Essentially uses Object-relational mapping

  18. APIs • Entity (core) • Entity API • Schema API

  19. Important data management concepts • Entities • Users • Taxonomy terms • Comments • Nodes • Fields • Entity + Fields = Bundles

  20. Bundle - Example • news_item (a node entity) + • Date (field) • Subject (field) = • “news_item bundle”

  21. Key entity hooks • hook_entity_info() • Entity (core) • hook_schema() • Schema API • Entity API • entity_create() • entity_save() • entity_delete() • entity_view() • entity_access().

  22. 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', • ), • '

  23. 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.",

  24. hook_schema() • Supports primary and foreign keys • Supports indexes • Field lengths • Precision • Signed / unsigned

  25. Data storage example

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

  27. 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 | Data storage example • TABLE: node • nid | 164 • vid | 164 • type | 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

  28. Viewing your data • Views module • Still a contributed module • Essentially a report writer • Complicated • Database API

  29. An example: Algoma University's Archive

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

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

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

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

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

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

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

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

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

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

More Related