From April 19-21, approximately 3,000 Drupalers descended upon San Francisco for DrupalCon. My attending was a semi- last-minute decision since I was already committed to SXSW and Educause this year. As luck would have it, talking to fellow Drupal developers at SXSW convinced me I should really be at DrupalCon the following month.

We’ve worked with Drupal for the past year and a half at Duke. While it is the most flexible CMS we support and has allowed us to do some really cool stuff, we’re beginning to face scaling challenges as our number of Drupal sites has grown. Most of our sites are standalone instances (with the occasional multisite), which makes updates a little unwieldy.  Also, we find ourselves installing many of the same modules on every site, so this process can be a little redundant as well. I’ve had a feeling for a while that our setup really isn’t as efficient as it could be, but had a hard time finding decent documentation or case studies on managing several Drupal sites in-house. So this is primarily what I was hoping to learn at DrupalCon: best practices for streamlining our development and maintenance efforts in an enterprise environment.

DrupalCon exceeded my expectations by a long shot. In fact, it just might be the best conference I have ever attended. The sessions were a great mix of general “how we did X” case studies and how-to’s for specific tasks. I can honestly say that I learned something valuable in every session. I’ll discuss some of my favorite sessions below. However, I also had some really great conversations with folks informally as well.

Arizona State University and Johns Hopkins shared their experiences of implementing Drupal in academia. Following their session, about fifty of us met for a higher education “birds of a feather” gathering. It was really interesting how Drupal is being implemented at other schools — from centralized multisite installs, to one-off standalone sites similar to our current environment at Duke. Although some setups sound more effective than others, it doesn’t sound like there is any one “right” way to implement Drupal on campus. We also talked a lot about getting Drupal buy-in on campus. Many suggestions reinforced those mentioned in ASU’s presentation: offer Drupal support, build community, supply common templates or other tools.

However, another method also emerged, one that seemed popular on many campuses: sneak Drupal in the back door. In other words, rather than launching with fanfare and switching the campus to Drupal all at once, try it out on a few sites. As users become familiar with it, word will spread and Drupal usage will grow organically. I feel that this is what is happening at Duke; lately, we’ve had more clients come to us explicitly asking for Drupal for their projects (it’s our practice, however, to select the CMS — either Drupal, WordPress or Cascade Server — only after establishing the functional requirements).

Personally, I didn’t feel like we faced any push-back from our senior leadership when we launched the new Duke.edu homepage in Drupal. But at the birds of  feather meetup, it sounded like a lot of colleges and universities did; particularly from executive level leaders who did not have confidence that an open source CMS could be robust enough for large-scale or high stakes projects. At one point during the session, one person from an ivy league university mentioned that they had a lot of trouble getting Drupal buy-in on campus — until Duke launched its homepage in Drupal last fall. Since then, that school’s senior leadership has embraced Drupal. So that made me feel all warm and fuzzy inside.

There was a core group of eight of us or so working in higher education who met up the first evening, before the conference even officially kicked off. Over the course of the next several days, we joined for dinners and the official parties and talked about how we were using Drupal at our respective schools. We represented a variety of institutions — San Francisco State University, University of Texas at Austin, and the University of Guelph in Canada to name a few. Besides Drupal, we also talked about other aspects of university web development: pricing models for services, how our web departments are set up, and what services we support.

DrupalCon was a wonderful experience. I loved the variety of the sessions, as well as the camaraderie I found in fellow Drupal developers, especially those in higher education. I gleaned a lot of useful information about how we can streamline the rollout and maintenance of our sites at Duke. We can make a lot more use of multisite installations instead of so many standalone sites as we manage now. We also should further investigate the use of Drush, a series of scripts that allow site administrators to run installs, updates, and other processes from the command line. DrupalCon SF 2010 concluded a month ago, but I’m still fired up about all the cool things I learned and great people I met!

My Favorite DrupalCon Sessions

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.

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.

Posted by Christina Dulude on Friday, May 21st, 2010 at 8:57 am.