Planet Drupal

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

As you may know the 15th of January is the birthday of Drupal. Dries has done crafts and posts about the celebration of Drupal in the past like the cake he made for the fifth birthday). This year we decided to create some stamps for the Drupal birthday.

Start: Monochrome Miniature Druplicon

As web developers and designers we get spoiled by the ability to make something really big and high resolution. The world of printing and stamps is a little different: stamps can really only do one color and they don't handle thin lines very well. That's exactly what the miniature monochrome Druplicon was made for. We originally used that Druplicon for our business cards but it works perfectly for stamps as well.

Last week was the amazing Do It With Drupal conference and Angela Byron wanted some updated contributor statistics for her presentation. So, I analyzed the commit messages for Drupal core to find who has been helping out and once again the process and the data are getting better and better.

This time I'm using direct database information from the cvs commit log tables and using PHP to parse it which means that it's easier to create rules for fixing usernames or eliminating bad data. I also pulled in company information from groups.drupal.org to get a rough sense of which companies, as a group, are contributing the most to Drupal core. AND, thanks to Dreditor the commit messages are getting cleaner and include information about the person who has done reviews on patches.

Remember, none of this data is really perfectly accurate, but it gives us a tangible sense of what is going on.

Attached are a CSV file and an OpenOffice.org spreadsheet with the data. They show the uid of the user from groups.drupal.org, their name, their organization (if they specified one), the number of times they were mentioned as an author of a patch, the number of times they were mentioned as a reviewer of a patch, and the commit ID where they were mentioned. The commit ID is useful when chasing down bad data so that I can improve the parser. So, if you find a problem please let me know the CID value so I can improve the parser. There's a chance that this could eventually make it onto drupal.org itself, but I'd like to improve the process first to understand whether or not that makes sense.

Enough with the process - it's time to name names!

Top 10 patch contributors to Drupal 7 core

Drupal core is very secure by default, but you can unknowingly open vulnerabilities with insecure configuration. An example of this is how allowing anonymous, untrusted users to use any HTML tag in comments opens a cross-site scripting attack vector on your site.

I'd like to introduce the Security Review module for automatically checking for the existence of insecure configuration and maintaining a secure Drupal site. With the first release come the following checks:

• Insecure file system permissions
• Insecure input formats
• Dangerous code in nodes and comments
• Printed errors
• Private files directory not set outside the web root
• Dangerous allowed upload extensions
• Permissions granted to untrusted roles

Security Review also looks for the common attacks of SQL injection/system probing and brute-force login attempts.

The module reports the result of its checks as pass or fail and provides details on an accompanying page. Checks may not be 100% accurate on every system so they can be skipped from being run. I often skip the error reporting check while on a development instance of my site. The checks are explained in detail and where applicable there are links to online documentation.

Future plans for the module include popular contrib module checks and notification support. I encourage you to give the module a run on your sites and let me know what you think in the comments!

There seems to be a new pattern emerging in Drupal and I want to let you know that the Token module has joined the bandwagon with a "Token Starter Kit"

History of the Starter Kit in Drupal: Zen Theming

When the Zen project started it's goal was to be a really solid base HTML theme with tons of comments in the templates so that a new themer could take it, modify it, and end up with a great theme. Unfortunately, that second step of modifying it meant that people ran into all sorts of support issues that were hard to debug and they were in trouble when a new version of Zen came out - they weren't really running Zen any more.

How to use the Token Starter Kit

The Token Starter Kit is meant to be similarly easy for folks to use. The idea is that if you just open up the token module itself and start adding tokens then you are "hacking a contrib" (modifying it) and you will have to remember to make those changes again when you upgrade. Bad news. It's also not particularly simple to understand how the module works (it's got includes, and hooks, oh my!).

Enter the tokenSTARTER module. Just copy the tokenSTARTER .info and .module files to a new directory in your modules directory, rename them, and rename all the functions inside to match the filenames. This gives you a clean place to start adding in your own tokens. So, go for it. You'll see that it's quite simple and all you need are two hooks.

Documentation on Token API

There's also an API.txt file and README.txt file which explain how to write tokens in general. Lots of great advice in there.

When a form protected by spam prevention measures such as captcha or Mollom is submitted with drupal_execute, validation can fail unless the spam protection is properly suppressed.

This blog post describes the background and solution to a bug that previously existed in the Signup Integration for Ubercart module (uc_signup), and explains the techniques used to fix the bug. It is written with developers and aspiring developers in mind, though other people interested in how Drupal works might also find it interesting.

drupal_execute is a function often used in data imports that allows a developer to take a collection of form values and submit them programatically.
A main reason to use drupal_execute over another technique such as user_save() is that with drupal_execute, Drupal calls the validation and submission functions for the form.

The Context: How uc_signup Uses drupal_execute

In the Signup integration for Ubercart module, we sometimes create a new user account and populate the user's profile with data that was submitted on a form separate from the core user profile form. In earlier versions of uc_signup, we created the new account with user_save, however this allowed crafty users to leave required fields blank by skipping the form and proceeding to checkout, so we switched to drupal_execute which ensures that the form's validation gets executed.

The Problem

The drupal_execute function is relatively easy to use -- just pass in the form_id and form values you'd like to submit to the form.

However, we soon got a bug report with one user reporting a validation error at the time that the new user account is saved, with the captcha module enabled for the user registration form.

We recently redesigned the Growing Venture Solutions site and I was given the task of completing and theming the new design. This was only my second theming assignment and it was a tremendous challenge and learning experience; I'd like to use this post to pass on some of the resources that helped me along the way. Maybe they'll help someone else?

The original GVS site was running the Marvin theme; since we’ve been growing it was time for a custom look. The first passes at the design and new logo were done by Don Hajicek and everyone was pleased with the overall style and particularly the leaves on the logo and on the “more” links. When I joined GVS I continued where Don left off by expanding his design to include more content elements, adding the navigation tabs and the footer area. (I like the little set apart yellow tab, although we're not sure if that color choice will stay.) I then moved on to Adventures in Theming.

Adventures, indeed. This image is a diagram Greg drew for me to explain the roles of the system administrator, site builder, developer, and designer. (“There are these overlapping bubbles, see?”) This pretty much sums up where I was starting from.

About a week in, when I was near the nadir of my learning curve confidence, I found this on Nick Lewis' site and I felt some relief; I was not alone: "When you first start, its going to suck: its going to be both boring, and confusing. Can you endure the unpleasant experience of watching yourself suck, while both confused and bored?"

I just attended a very interesting session at Drupalcon Paris called Paying for the plumbing. It's a panel involving Allie Micka (Advantage Labs), Angie Byron (Lullabot), Karen Stevenson (Lullabot and recently a freelancer), Tiffany Farriss (Palantir relatively new to Drupal but a long lived company), Eric Gunderson (Development Seed).

Some choice quotes on coordination and business of open source

After some introductions and Allie saying that she didn't want to hear the same old tired platitudes (which was a brilliant start to the session) we got into some discussion with the panel and the audience. Here are a few quotes and paraphrases of what people had to say.

Tiffany Farriss of Palantir gave the perspective that we should

Budget in 10% to every project for "patching."

I assume "patching" means communicating with the module maintainer and re-rolling the patch and making it awesome.

Which is a decent point, we do need to kind of just do this as part of our normal business, but that doesn't pay for the big things nor the "plumbing" but just for incremental improvements.

Further, Tiffany said:

Require all your code to be GPL and tell clients you're going to release it and announce it as best you can.

Which is a great point. Drupal.org requires all code hosted there to be licensed GPL Version 2 and later and if your client claims it isn't then there can be big problems for all involved.

Benjamin from Agaric Design Collective said:

We need better coordination tools.

Which is pretty true, and we have a decent tool at Projects Needing Financing. This points out what I think is the real problem of the whole collaboration idea: coordination.

The only way coordination on a feature works for us is when 2 of our customers want the same thing and we do all the work.

The code freeze for Drupal 7.x is looming large on the horizon. From that point on we will be limited in what kinds of changes we can get into Drupal core. For some the code freeze is a time of relief: it means we are down to bug fixes and the final release should be coming soon. For others it is a hard time - bug fixing isn't always as fun as adding new features.

So, as we head into feature freeze it seemed like a good time to run some statistics on who has been contributing the most to Drupal 7.x so far.

Contributors to Drupal 7.x. Through August 10th

Following on from previous times that I've run these stats, I've published documentation of the process to get the data on groups.drupal.org. This time I went straight to the commit messages stored in database tables on drupal.org This has the benefit of counting new files as well as old files (the last times I did this it only counted changes to existing files).

So, who are the top 10 people based on the number of times their name is in a commit message?

The total number of mentions is 3133, so those top 10 are responsible for roughly 33% of the code. On the flip side, people with 3 or fewer mentions are responsible for roughly 15% of the code. We still have a long tail of 222 people who are mentioned in only one message. We see a fairly typical "long tail" distribution: the people who are most involved do a lot of the work, but the people who only get mentioned a few times each are still responsible for a large number of commits when aggregated together.

Ezra Glidesgame has been writing a module to integrate the Signup module for managing event registration with the Ubercart e-commerce module: Signup integration for Ubercart (short name: uc_signup). The uc_signup registration process was designed to support a wide variety of use cases (one user potentially signing up multiple other users for different events, in different quantities) while still being easy to use. We wanted to see what users thought of the preliminary uc_signup registration process, so in June we ran a small usability test here at the Growing Venture Solutions office. The test revealed several subtle and interesting findings that applied to the uc_signup module, the Ubercart checkout process, and specific aspects of the client site's configuration.

First, some background on the project

AUSSIE provides professional development in the field of K-12 education. One of their services is to offer workshops around the country, with registration done through their website. Uc_signup is being written to give AUSSIE more control of the look and administration of their sign-up process, and internalize their events management, which is currently being hosted by Eventbrite. The improved Aussie site is scheduled to launch in August.

About our Usability Participants

We recruited 4 participants having the following profile characteristics:

• Two men and two women between the ages of 29-36
• All with general office experience and good computer proficiency
• All use the internet daily, with a range of 3 to 40 hours per week
• Internet purchasing comfort level: comfortable to strongly prefer
• Three of the participants had previously signed up online for classes or workshops