Planet Drupal

We are driving ourselves crazy, folks. Choosing modules is really hard. And it's only getting harder on enterprise Drupal sites (and enterprise just means big teams and with big sites with big requirements).

A recent conversation on twitter started by Drupal rock star Katherine Bailey shows how module selection on a big site can drive you crazy:

So, today I'm going to lay out some ideas I've found for reducing the madness: choosing good modules both as an individual and as a member of an enterprise Drupal site. Of course the enterprise practices build on the set of guidelines for an individual site builder. I'd love to get feedback on other techniques people have used for module selection in big team, big site, enterprise environments.

Module selection best practices

1. First, identify your need and try to be as generic as possible. If you say "Building an event system" you may skew your results toward the Event module when what you really need is some combination of Date, Calendar, Views, and Signup.
2. Next, search around for modules that match what you need and look for recipes and tips from blogs or groups.drupal.org. This is often where you will find great advice on which is the best module to choose. Try the similar module review group which is an amazing resource.

Earlier this year we supported the IxDA in launching a new version of their IxDA.org site. One of the many interesting new features of this site is the ability to sort content by "hotness". The goal of this tool is to create a list of interesting content on the site. Their analytics show them that most people who are involved in the site visit it at least twice a month. So, they wanted a system to highlight content over the last two to three weeks. Enter the radioactivity module.

Radioactivity Module for Drupal

The Radioactivity module works on the concept of adding energy to a piece of content which then "decays" (or diminishes) with a particular half-life. The exact behavior is up to the site administrator, but on IxDA.org we originally set it up with values roughly similar to:

• Posting content adds a lot of energy so that the hotness favors recent items.
• Commenting on a post adds some energy
• Voting up adds a bit of energy, voting down subtracts some energy
• Favoriting a post adds some energy as well

We've got a few other elements that affect energy to help offset any potential gaming.

We set the half-life for decay to 15 days. So, if a piece of content gets posted and 3 comments and 2 vote ups and 1 favorite with 100 views on the first day it will have about 500 units of energy. If it gets no new energy, it would decay down to 250 units of energy after 15 days, and then down to 125 after 30 days and so on. Eventually the energy and decay are really small and for efficiency the module simply deletes all records with less than 2 units of energy.

Extending the Radioactivity Module

Carl, Ezra, Lisa, and I will be at DrupalCon Copenhagen later this month. We're giving a handful of sessions and running a training. So, if you're in Copenhagen on August 23rd and interested in getting security training, for identifying and fixing common security risks on your site, join us! Check out Security: Process, code & hands-on training to signup.

Our Sessions at Drupalcon

• The Future of Drupal.org
• Theme Preprocess Functions: an Introduction
• On the Importance of Done: Drupal & Scrum at the Economist
• Views: The Key to the Drupal Castle
• Drupal Security - Configuration & Process

Drupal Security Paper update

Last week we published a minor update to the Drupal Security Paper, a report on the state of Drupal security and how it addresses security risks and concerns. We expanded some of the Security Advisory analysis data and made a few minor corrections. If you have not read it, now is a great time to take a few minutes and give it a read.

One measure of the momentum of the fine Drupal project is the number of people who are creating contributed modules on drupal.org.

The Drupal contributed projects are stored in a system called CVS and data about that is stored in some database tables that keep track of each change by each person. At the request of some fine folks who are working on important things, I got interested in the idea of the trend related to people committing code to the drupal.org CVS server. Here is the data graphed by the number of committers per month. It is not the number of commits, which would show how active those people are, but the number of people which shows how big of a group of people is doing this work.

Also, this is only about the contributed module and theme area and not about Drupal core. Drupal core commits are done by a very small group of people after that small group reviews the code contributed by hundreds of contributers. So, this really shows activity of the non-core projects.

I've labeled 4 points on the graph.

1. 2006 through Drupal 5.0 slump

Point 1 shows a peak at June of 2006 followed by a slow down until the trough at August of 2006 and then some small increases until December of 2006. Then there is a huge increase in people in January and February of 2007 which is also when Drupal 5.0 was released.

2. 2007 Follows a similar contribution trend

Last week at DrupalCon SF we released the Drupal Security White Paper on drupalsecurityreport.org. The paper has been under development for the last several months and we worked hard to complete it in time for DrupalCon.

Addressing ongoing questions about Drupal security, the paper analyzes the Security Team's Security Advisories and discusses how Drupal 6 and 7 address common and critical security risks, including those of the OWASP Top Ten.

We couldn't have done it without the help of our sponsors, including Cydeck and Examiner.com among others, and without the help of our reviewers. Thank you!

If you're evaluating Drupal for use on your site, this report is for you. Or, if you're just curious to know more about Drupal and how it addresses security risks please give it a read.

We've got a few exciting announcements here at Drupalcon. Two of those are related to a new site we launched yesterday, CertifiedToRock.com.

Woven Druplicon Hats

We got some beautiful hand-made, wool Druplicon hats from Peru with the help of my good friend Fernando Garcia (develcuy) and the artisans that his lovely wife Nancy works with. Now we're ready to give these hats away - for free - but of course there's a catch ;)

Certification for Drupal with CertifiedToRock.com

We've built a super simple (and yet, we think, still valid) certification for Drupal users based on their involvement with the Drupal project. It's located at CertifiedtoRock.com where you can enter a drupal.org username and see the corresponding certification level of that individual. Learn more about CertifiedToRock.

If you want a hat, tweet a link to your score with @certifiedtorock and we'll hook you up if your score is 6 or higher. After noon on Wednesday we'll be giving out hats to anyone with a score of 5 or higher.

I like building forms. So much so that I've even been teased about it. Despite that I want to share how multistep forms have changed for Drupal 7 and to expand on how you can use variable functions to achieve cleaner and easier form step logic, including easily moving backwards in forms. Understanding multistep in Drupal 7 was prompted by my need to create easy forms for an internal GVS project that will hopefully launch soon.

Multistep in Drupal 7

In Drupal 6 to carry data back to your form builder you set the storage key of $form_state in your submit handler. In Drupal 7, upon return to your builder after submission, you carry data over by keeping the Form API from pulling the form array out of cache*. You do so by setting $form_state['rebuild'] to TRUE in your validate or submit handlers. Another change is the first argument of your builder must be $form because of changes to drupal_get_form(). &$form_state is now your second argument to your form builder.

Update: 'rebuild' existed in Drupal 6 (thanks Wim) but now seems to be required for multistep to work in Drupal 7.

Drupal 7:

Let's look at a example:
<?php
// multistep_simple, our form builder function.
function multistep_simple($form, &$form_state) {
// Check if storage contains a value. A value is set only after the form is submitted and 'rebuild' is set to TRUE.
if (!empty($form_state['storage']['myvalue'])) {
// Display a message with the submitted value.

The D7CX movement is based around the idea that while it's really important that we launch Drupal 7 by finishing off the critical issue queue it's also enormously important that we have our many contributed modules ready to go the day that Drupal 7 is launched.

Drupal core is an amazing piece of software, but Drupal core without the many wonders of contributed modules and themes is nowhere near as much fun.

GVS Hosts D7CX Sprint Day

So, April 4th we are hosting a D7CX Sprint Day here at our office. We will provide power strips, internet, coffee, camraderie. You should bring your laptop, and some skills in testing out and upgrading Drupal's contributed modules. The sprint will run from 9:30 AM until about 6:00PM - but you are welcome to show up for any part of that time.

Some possible tasks:

• Rewriting documentation for Drupal 7
• Helping to write simpletests so that contributed modules can benefit from a test-driven-development cycle much like core has benefited from it
• Creating patches for the modules and themes to work with the new api.

Folks will be available to help provide instruction in checking out code with cvs, rolling patches, and posting responses in the issue queue.

Some people on hand with specific module experience

• Greggles maintainer of Pathauto, Token, Comment Notify among others.

DrupalCons are great for learning new things and the conference in San Francisco this April will be no different. What will be different is that this year there are formalized training sessions happening the day before the conference really starts. If you want to get a more structured day of training before the somewhat unpredictable sessions start, you can.

Training sessions from GVS: Security and Site Building

The team at GVS is teaching two training courses and offering a handful of sessions. Our security training course was just increased to hold more participants and our course on site building is also looking to fill up. If you're interested in either please sign up soon!

GVS Proposed Sessions for Drupalcon

Session voting just started and we've proposed a variety of sessions, including training, module maintenance, using theme preprocess functions, and site-building. Here's the full list:

• Security for site admins
• Security for coders/themers (including how to "hack" a site)
• Module building workshop
• Theme preprocess functions
• Recipes and best practices for beginners