Ann Arbor Drupal Users - 28Jan08

Let's separate the concept of writing a module into 3 categories.

Every site will have its own site specific module. These are the changes you want to make via hooks to avoid forking your code. For instance my last site has a module that implements the below hooks. This module only modifies core and contributed modules with out really adding any new functionality.

• Hook_form_validate - a contributed module didn't have enough validation so I added some more.
• Hook_form_alter - side wide form changes (remove some fields, change weights, increase title to 255 characters, ...), form changes per role, change specific forms to accept arguments so I can prefill fields depending on the path the user used to arrive at the form
• Hook_menu - remove/change some menus that can not be edited from admin section, created dynamic menus that depend on variables like user, role, ...
• Hook_user - Change default of contributed module at the time of user registration
• Actions - site specific actions to be used with the actions and workflow module

http://api.drupal.org is the official source and documentation of Drupal calls.

New module that supplies functionality that doesn't exist as a contributed module already. This must be generic and abstract enough to be deployed on any site.

• Of course you should look at the Module Developers guide in the handbook - http://drupal.org/node/508

• The Module Builder module can be a great place to start. http://drupal.org/project/module_builder
  A module which auto-generates a skeleton or "scaffolding" for a module, along with hints on how to fill them in. Useful for newbie developers to learn how hooks work, and seasoned developers who are too lazy to look up what arguments a function has to take. ;)

• The Snippets in the handbook can also be a great resource - http://drupal.org/handbook/customization/snippets

• And other existing modules.

Sometimes you find a module that does almost what you want but there is no real way to hook into it and you are forced to fork the module. It would be best to help the author of the module to bring in the functionality you need. But sometimes the functionality you want is outside the scope or even counter to the principles of the module. In this case you would fork the module with your own code.

This happened to me recently with the BIO module. The module implements hook_init. I want to edit how it works but there is now way to rollback another modules implementation of a hook. So I am left with forking the BIO module and substituting my implementation of hook_init. I created a patch file so I can quickly patch the module when a new version is available.

I avoid writing modules at all costs, often to a fault. Don't build what you can steal (appropriate)! But when you find yourself in uncharted waters build smart. This means take time to learn the Drupal APIs at http://api.drupal.org