Planet Drupal

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

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.

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.