DC2009:Managing Drupal Web Projects

Description

This session will dive deep on best practices for designing, developing, and maintaining Drupal web sites. Topics will include template design, module selection, version management, and other configuration best practices.

== Session Notes ==Why Drupal? • Good solution for non-profits because there are a lot of vendors already working with Drupal. • Provides different ways to achieve functionality. • Configuration is very difficult out of the box, but programmers are easy to come by, and easy to replace if need be. • DC is a Drupal hotspot. • Joomla is not sophisticated for many orgs. Drupal Background • Core Drupal code + Contributed modules (developed by any person and enhanced by others) o Modules as plug-ins to the core CMS programming • Different Drupal developers have different areas of Drupal expertise o Core Drupal configuration person o Costume module development person o Design/theme CMS person • Starter theme/templates exist • Zen most widely used theme • As new modules are implemented, the theme designer controls their style and appearance. • Developer needs to be engaged in the design process because Drupal has a default output style. The more customized design will create more costs. Choosing Vendors • Lots of transparency in vendors’ development o Development site is on a secondary server so that the client is able to see the process going into its creation • Look at example sites, and be sure that they are within the desired budget • Ask for references • Ask if they are maintaining Drupal sites after configuring and developing it. • Ask about source-code management and backup • groups.drupal.org—there is a DC group of developers Drupal integration • CiviCRM and Salesforce integrate well with Drupal • Drupal and Paypal integration • Easy to communicate with MySQL Drupal Challenges • Terminology is less intuitive o During the testing stages, have client-developer Q&A session • Configuring the production, development, and staging sites can be exportable, but not always the case • Too many modules o Overexcitement over new functionality o Can lead to decreased site performance • On-going updates o Need to consider the cost as on-going • i.e. security fixes every two months  These are typically quick fixes and easily applied • i.e. annual version releases  Drupal only supports the latest two releases  Depending on how complex the modules/site theme, can become a web re-design  If not updated, won’t receive the security fixes. • Not unique to Drupal, all CMS will have these updates When not to use Drupal • Depends on the content, simple content doesn’t require the complexity of Drupal • One-person shop, check out wordpress.

Yearly Upgrades are necessary for all CMS Have designer and developer communicate when creating the web re-design Find a developer that has transparency in building the site