Presenter commentary for "Drupal Module Development Kickstart"

When I was looking for topics to present at Drupalcon DC, I quickly realized I have not seen a Drupal module development presentation in the style I'd have liked to, so I should better try and deliver it myself. While playing with the idea, Peter Wolanin expressed his deep interest to join, especially since he shared the same views relating to what we should cover.

We designed our presentation to be complimentary to other presenatations, like the Gentle intro to Drupal Code which nicely explains high level concepts, but does not show the depth of what people can do, or the fun Pants.module session way back from Drupalcon Brussels, which shows a bit too much of what Drupal can do without explaining what people should not eventually do.

Interestingly, our session started off with why people should not write modules. After all, there are more then 4400 projects on, on which you can base your sites. If someone else maintains your code, it gets bugfixes and improvements while you sleep, you are on vacation or you sit at a presentation. However far these precooked modules get you, you will always find missing items which need custom development. Then and only then should you think about writing modules.

Therefore we focused our session around the alter hooks, modifying existing menus, form layouts, submission workflows, and so on. We did include an example of a complete module with SQL code and all, but quickly jumped to talking about why you should not do this at home. We might have picked a bit over-the-top examples for those not familiar with PHP, but the basic idea was to show off what you can achieve with a few lines of simple code, and then let people read the resources (books, cheat sheets, articles) with that in mind.

for those about to code we salute you

All-in-all, I think your module development should enter this era, if you did not focus already on this approach. Get your general improvements to the modules in question and use the alter, nodeapi, user, etc. hooks to modify behavior whenever you need to add, remove or modify capabilities for your own needs. Less code to manage for you, better for the community that you find the bugs in the common modules, easier the upgrade path when it comes to move one version ahead.

Peter was quick to post our slides while in DC with our speaker notes included and the sample module we compiled to contain all our examples. The sample code is a single installable Drupal 6 module with all our examples implemented. Happy coding!


akahn's picture

Too bad I missed this session. Thanks for posting this discussion of it, I'll be looking over the slides!


Add new comment