Drupalcon Boston: Day 4

A Developer's Assistant: Using Coder for Module Developers and Maintainers

Session led by Doug Green from Civic Action, maintainer of the coder module.

The Coder module aids developers in adhering to Drupal's community coding standards as well as helping with security pitfalls and upgrading modules from one version of Drupal to the next. Specifically, Coder reviews:

• style (lots)
• comments (lots)
• sql (some)
• upgrades (lots)
• security (some, but not a lot)
• performance (well - not so much)

Coder mainly uses regular expressions to perform the various checks. It is able to check modules regardless of if they are enabled or not. Doug announced today that the module now supports drush (=drupal shell - running Drupal from the command line).

Doug recently ran coder module against over 1500 contributed Drupal 5 modules and core. He said it didn't take all that long (less than 30 minutes) and the most common errors were:

• 2 space indentation with no tabs
• missing spaces
• extra trailing spaces
• string concatenation
• curly braces
• camelCase
• indent second line of comment

Doug also took the liberty of (mostly) upgrading views (version 1) to Drupal 6. He said he got about 90% of the way complete in about 3 hours utilizing Coder module - even demoing a good portion of the add/edit view functionality. He's only going to release it with Earl's (the maintainer of views) blessing.

The future of Coder will bring:

• 7.x upgrade review
• better security reviews
• create patch files
• css/javascript files (possibly - this will require the addition of some type of file-type awareness for each test)

Tracking Event Results

This session was lead by speed-talked Karen Steveson. The presentation consisted of implementing a complex web site senario using events with views and CCK. The senario Karen came up with was a series of fishing tournaments complete with participants and scores.

Partial list of modules used:

• CCK computed field (used to grab extra information from nodes referenced)
• CCK date
• CCK user reference
• CCK node reference
• views calendar
• views calc
• auto node title (used to automatically set the title to the "tournament name" + "team name")
• Flickr
• Flickrfield

Karen was kind enough to put just about everything you need to recreate what she did online - grab it here.

Some valuble tidbits she mentioned:

• Computed fields only update themselves when you update the node.
• You can make views the items in select lists for node reference when editing the content type.
• An easy way to create a new calendar view is to start with the default calendar view and building on top of it.
• You can create tabbed views by using two-level urls - something like "results/tournament" and "results/team". You'll also need to set up the arguements to work with the second part of each url and utilize the menu settings. An easy way to do this is to create one, then clone it and make the changes.

It's hard to get all of what Karen showed in a few paragraphs, as she appeared to be hopped up on Jolt cola. Regardless, it was a great presentation showing what you can do with views and CCK when you know what you're doing.

Zen and the Art of Drupal

Jeff Eaton (FormAPI, VotingAPI) and James Walker (BlogAPI, OpenID) from Lullabot presided over this session about the philosophy of development within the Drupal community.

Not so random notes:

• Drupal is no longer the new kid on the block - it is regarded as the top open source content management system available today.
• Drupal's core code base has grown from 35,000 lines in 2005 to 50,000 lines of code today.
• Drupal's contributed code base has grown from 300,000 lines in 2005 to 1,800,000 lines of code today.
• In the past 3 years things have become more granular now as far as contributed modules go. More people are using views+cck+calendar to do events instead of just the event module. This provides more flexibility, but more configuration.
• As move forward, additional layers are being designed and added (XML, RDF, configuration management, etc...)
• Minimizing design debt is important by refactoring as often as possible. Drupal avoids large amounts of design debt by changing APIs in major Drupal releases.
• Hacks can be useful, but don't necessarily have to be made into a module. If you do make a hack, be sure to document it for your(future)self.
• They also stressed simplicity in user interfaces. This often means less "stuff" on the page, rarely it means "more".