My favorite DrupalCon talks

Over the course of my three days at DrupalCon, I attended twenty talks on everything from best practices in building large-scale Drupal sites, to tips on module development and theming. I found absolutely every session valuable (seriously -- I'm not just saying that to be nice). There's not one session I walked out of thinking, "Wow, that one was a bit of a dud." And how many conferences can you say that about? There were many sessions scheduled during the same time slot; I wish I could have cloned myself. Luckily most, if not all, of the sessions were recorded. The audio and slides from presentations are linked off of their respective pages.

That said, however, there were some sessions I found especially useful. I will summarize them here, below.

Case Studies in Academia: Drupal at ASU & Johns Hopkins Knowledge for Health

This was a joint presentation between Arizona State University and Johns Hopkins. Although both presentations were very good, I'm going to focus on the ASU portion for this summary since most of the takeaways from their presentation directly correlate to challenges we face at Duke.

The university's Web Consulting Services team provides a shared web hosting service, core services, contracted development. Additionally, the Web Consulting Services team wrote a Drupal module to integrate with the central authentication system, as well as a Zen subtheme with the ASU look and feel.

ASU runs an enterprise level Drupal environment, which means that it is higher availability, and has access to HR systems such as PeopleSoft. Their Drupal instance uses the Services module, which taps into central systems and exposes the data as web services which can then be consumed by other sites on campus.

Web Consulting Services also provides support for uses and contract support for departments. The group also supports the local community of users. The shared hosting environment can run any PHP application, but Drupal is the only one officially supported. When site owners sign up for shared hosting, they install Drupal in the account's home directory (like commercial shared hosting such as GoDaddy). The shared hosting system has an installation profile system which includes Drupal, as well as WordPress and MediaWiki, among others. Web Consulting Services provides packages such as the custom authentication module and the ASU theme. Next steps include building installation profiles in Aegir, which could create new sites at the click of a button. 

In 2006, ASU IT was decentralized with little collaboration among groups. There were many CMS's on campus and no big picture vision for user experience or brand. In 2010, the university is largely Drupalized. There is some variation from site to site, but there is a consistent header, navigation and branding. 

The biggest obstacle they faced in this process was politics. Site owners were territorial, there were silos of development, and no incentive to unify. Furthermore, there were no supported tools or community. Therefore, Drupal had to be as attractive as possible to make site owners actually want to come over. 

The first "carrot" was the Drupal platform and a suite of commonly used modules in the shared hosting environment to make hosting as simple as possible. The second incentive was really building up the community. They started two users' groups: one for the web community in general, and the ASU Drupal Users' Group (which meets during business hours, so users don't have to give up evenings to attend). Web Consulting Services also offered Drupal office hours for informal help, and training through Lullabot (which groups paid for). Support and outreach was key; engaging users and making extra effort to help if they had problems.

Today, ASU has Drupal buy-in from key consistencies on campus and a huge hosting environment (25 servers with 100 sites each. Not all of these are Drupal, but they estimate 200-500 are active Drupal installations).

There is now a consistent look and feel for users, as well as a consistent support experience for web staff. Drupal is the only CMS they support; they do not have to support other products or people's home-grown applications. Repurposing of content is another key feature; events published to the Events site can be pulled into other sites.

The ASU shared hosting environment is built on DirectAdmin, with around 2500 domains. Some of these are high-performance servers that run only one high-profile site, such as the library's site and the news site.

Next steps at ASU? The first is to address the growing pains that have resulted from the Drupal switch. There are 500 Drupal sites that are maintained by different people, and many aren't maintained on the code level. Content owners are beginning to worry about maintenance, so Web Consulting Services is investigating centralized hosting options such as Aegir or hosted options for sites that do not need a lot of custom functionality.

Drupal Site Security for Coders and Themers

This presentation offered suggestions on how to make Drupal sites less vulnerable to attacks. We need to worry about security in a prioritized way. Cross-site scripting (XSS) through contributed modules is the most common problem, along with cross-site request forgeries. The Drupal database API is relatively secure by default, so the most common vulnerability on the web -- SQL injections -- is less of a problem in Drupal specifically. In fact, this was the primary takeaway from the talk: if developers use the API correctly, they will be relatively safe.

Custom themes tend to be especially vulnerable to XSS. To protect against these attacks, it's important to read the tpl.php and default functions in core when building out your own theme. Developers and themers should work closely, with developers handing off only sanitized variables for the theme layer. For each variable, developers should ask themselves: Where does this data coming from? And can a user change it? In what context is this data being used?

Cross site request forgery -- taking a particular action without consent -- is another vulnerability that can be found in contributed modules not built correctly. To combat this, the Drupal API includes tokens in the URLs for every form that must be included when the form is submitted with the drupal_get_token() function.

The db_rewrite_sql() function is how module developers should use Drupal's node access system; the function excludes the nodes that the user is not supposed to see. To combat SQL injections, %d in a SQL query forces an integer value. It's also important to add the clause "AND published = 1" to ensure that content being displayed is actually allowed to be displayed.

Two resources mentioned in the talk were Cracking Drupal and Safe String Theory for the Web, which described ways strings can be sanitized in different contexts such as display on the web or email. Additionally, this page contains examples of security vulnerabilities on contributed modules. The Drupal Security Report is a white paper detailing how Drupal maintains security. 

Planning and Executing a Successful Drupal Implementation

This session was presented by folks from Phase2 Technology, one of the leading Drupal development firms. In addition to the technical details of complicated Drupal projects, working with stakeholders and defining scope are crucial skills as well. Our team functions like a small development shop, so I was curious to see how the big guns manage client expectations and scope creep.

Customers who know a little about Drupal present their own set of challenges. They often underestimate the amount of work involved, chalking it up to installing Drupal core and a bunch of modules. It's important to head this off at the pass and explain that Drupal is a platform just like any other, rather than being a website out of the box.

Communicating effectively may seem like a no-brainer, but it's easy to overlook. The presenters suggest using a project portal like Basecamp or OpenAtrium to benchmark steps in the process, rather than just sending emails back and forth. Status reports, regular updates and in-person meetings are as important as in any other web project.

Don't forget that the Drupal back end can be difficult for newcomers. Therefore, it's important to train stakeholders properly. In-person training is the most effective way to get people up to speed. Administration guides are necessary, but too much documentation can get stale. A "starter guide" is a good compromise; a basic guide shows the users how to post their first article on the site and they can learn the more complicated features later. Developers can also link to documentation from the administrative interface.

Encourage stakeholder testing early on. This has many benefits. It helps developers understand if the system meet their needs and makes the client accountable for their own success. Testing also makes them part of the team; developers should not be the only ones working long hours on the project; stakeholders should be right along side, too.

Putting the right project team together is crucial. Phase2 assembles Developers, designers, project managers, web producers, and analysts (who understand the entire problem and translate that into a Drupal solution). Phase2 also stresses role flexibility. The team must function as a soccer team with overlapping roles rather than a baseball team where each person focuses on their own task.

While not Drupal-specific, working in iterations (a la Agile) is a good practice because it keeps scope under control. The backlog of tasks is completely transparent, so tasks can be reordered and there are no surprises. A task management tool makes this easy; Phase2 uses Jira. 

In addition to identifying the site's goals and audience, it's also crucial to understand how the site's editors work and what role they fill. Asking stakeholders what other sites they like and why can also help define expectations.

There are some Drupal-specific things we can do to make things easier for our clients. Including help text for content types is simple but effective. Presenting a clean administrative interface is helpful. Syncing up the site's CSS with the WYSIWYG editor is a nice touch, as is not showing all the available WYSIWYG buttons so users don't get overwhelmed. 

Another helpful tip suggests we don't assign specific job functions to specific roles. Rather, one role should include many job functions. It's also good practice to scale back permissions for less experienced uses so that they don't get overwhelmed.

Making Drupal Admin Simple

I expected the Making Drupal Admin Simple session to explore practices relating to Drupal deployment and server administration. However, the "admin" actually referred to content administration and usability for content editors, and I gleaned many useful tips.

Choose the CCK form field that best matches the data. For example, use node reference field to reference another node, and group fields that are similar. At first, it might seem most logical to arrange fields in the order they will be displayed to the public; however, it's actually easier for content editors to put fields that will be updated frequently near the top, and less frequently used fields farther down. 

We can make the editing experience easier by approaching the edit function the way a visitor would access pages, through the front end. The best way to do this is including "edit" links for authenticated users on nodes themselves. 

Of course there are cases when users will need to go into the content listing to search for content to update. Some modules can make this process easier. Content Management Filter is a module that provides additional filtering options such as author, title and publication date.

You can make content searchable with exposed filters in custom Views. Node Relationships is a module that allows two-way relationships between nodes (for example, a "related content" field that allows users to easily search for nodes within content edit mode itself). The Node Reference URL Widget module allows a node to be prepopulated with content from another node. Removing hurdles between the user and editing the node is key.

In theming, we muse allow navigation to content through the front end, including search, and allow unobtrusive edit options. One example of this is the option in Views to display an Edit link for each node that appears on hover over the node.

Although we want users to be able to edit content through the front end, it's also important to choose a good administrative theme as well. The presenters demo'ed Admin 2.0 module with the Rubik theme, which provides a very sleek interface. I've actually used this module on a couple of projects, so it was nice to reinforce its usefulness.

Admin Menu module is another way to put an administration menu overlay on the regular page content.

Provide help within the system. This includes using the CCK help fields and providing meaningful field descriptions that tell the user how the field relates to others. Help Inject lets you add additional help contextually.

Drush

Drush is a series of shell scripts for Drupal that make the administration of Drupal sites easier and faster. It can live anywhere, but creating an alias makes calling it easier. The presenter showed us how to install it on a Unix system and some basic commands.

For example, the command:

drush dl drupal

downloads the latest version of Drupal to the current working directory.

And:

drush dl cck views

downloads the CCK and Views module. And:

drush enable views cck

enables them.

Drush also allows you to run cron, download themes, update Drupal core, update modules, and a variety of other tasks.

Drush Make is an extension for Drush that creates a working Drupal install.

It reads in a flat text file, similar to a .info file, and downloads the projects specified.

For example, your makefile might read:

core = 6.x

projects[] = cck

projects[] = views

Which would download the current versions of Drupal 6, CCK, and Views to the server.

Drush Make is very exciting because it allows us to make distributions. This would be a great benefit to our processes at Duke; right now we have several standalone instances, most containing the same common modules. Currently, we have to download each of these modules separately and install them on the server. With Drush make, we'd just have to run our makefile, and all our favorite modules would be installed in one fell swoop.

I'm also really excited by the idea of updating modules and core through Drush. Right now, we're using Subversion, albeit somewhat half-heartedly. But we still have to touch each instance anyway, so this process really doesn't save much time. However, with Drush, it sounds like we would be able to save substantial time in updating.