Dave Reid

I know it seems like a far distance away and as much as you'd like to ignore it, Drupal 7 is coming and it will be awesome. Some ambitious developers have actually started with Drupal 7 version of their modules, but what if you just want to get a little head start? I'll show you a few ways that you can help prepare your Drupal 6 modules now to help make life easier when you full port to Drupal 7 later on. To see a list of all the current 6.x to 7.x module changes, view http://drupal.org/node/224333.

1. Split your hook_nodeapi($op, ...), hook_user($op, ...), and hook_block($op, ...) functions into hook_nodeapi_op(...), hook_user_op(...), and hook_block_op(...). See http://drupal.org/node/224333#remove_op. Here is an example of how you could prepare/split your module's hook_user($op):
   
   <?php
   /**
   * Implementation of hook_user().
   * @todo Remove in Drupal 7.
   */
   function mymodule_user($op, &$edit, &$account, $category = NULL) {
     switch ($op) {
       case 'form':
       case 'validate':
         $func = 'mymodule_user_'. $op;
         return $func($edit, $account, $category);
     }
   }

   /**
   * Implementation of hook_user_form().
   */
   function mymodule_user_form(&$edit, &$account, $category = NULL) {
     if ($category == 'account') {
       $form['mymodule_setting'] = array(
         '#type' => 'textfield',
         '#title' => t('MyModule setting'),
         '#default_value' => isset($edit['mymodule_setting']) ? $edit['mymodule_setting'] : '',
       );
       return $form;
     }
   }

   /**
   * Implementation of hook_user_validate().
   */
   function mymodule_user_validate(&$edit, &$account, $category = NULL) {
     if (isset($edit['mymodule_setting']) && $edit['mymodule_setting'] != 'foobar') {
       form_set_error('mymodule_setting', t('MyModule settings is not foobar.'));
     }
   }
   ?>
2. Change your db_query() parameters to an array of parameters keyed by named placeholders. Drupal 7 has a great new Database API (DBTNG) that uses arrays of placeholders. You can safely convert your D6 db_query parameters to arrays now; then when you actually port your module to Drupal 7, you only need to change your %d, %s, etc to the same named placeholders as your parameter array's keys. See http://drupal.org/node/224333#dbtng.
   
   <?php
D6 BEFORE: $query = db_query("SELECT nid FROM {node} WHERE nid > %d AND title = '%s'", 20, 'foobar');
D6 AFTER: $query = db_query("SELECT nid FROM {node} WHERE nid > %d AND title = '%s'", array(':nid' => 20, ':title' => 'foobar'));
D7: $query = db_query("SELECT nid FROM {node} WHERE nid > :nid AND title = :title", array(':nid' => 20, ':title' => 'foobar'));
?>
3. Drupal 7 supports a dynamic-loading code registry and all modules must now declare their code files in their .info file. You can add these lines to your module's .info files now! See http://drupal.org/node/224333#registry.
   
   name = MyModule
description = This is really your module, not my module.
...
files[] = mymodule.module
files[] = mymodule.admin.inc
files[] = mymodule.pages.inc
files[] = mymodule.install
4. Make sure all your module's update functions have a small, one-line Doxygen function comment block. This documentation will actually be displayed in Drupal 7's update.php. Instead of update numbers, we get to see what the updates are actually doing! See http://drupal.org/node/224333#update_php. While you're there, double check that all your update functions return some kind of array. Not returning an array causes errors.
   
   <?php
/**
* Adds a new mycolumn column to the mymodule table.
*/
function mymodule_update_6020() {
  $ret = array();
  db_add_field($ret, 'mymodule', 'mycolumn', array('type' => 'int', 'default' => 0));
  return $ret;
}
?>
5. Write test suites for your modules! Drupal 7 includes the SimpleTest module in core, but you can get nearly the same exact module in Drupal 6 with SimpleTest 2.x. Writing tests for your modules is a great way to make sure that everything still works properly when you make any kind of changes, big or small. Be sure to check out the testing documentation and standards!
6. If your module creates any hooks or has an associated API, add examples of these hooks in mymodule.api.php in the module's directory. This not only helps other developers understand the provided API a little easier, but also gives IDEs the hook information. This will also bring us a step closer to being able to have a searchable contrib API like api.drupal.org. See core's system.api.php for an example of this and also see http://drupal.org/node/224333#api_php.
7. Be sure to mark specific Drupal 7 todo's with Doxygen todo comments (//@todo This is something to do!) so you can easily find them later on. Little thing to look out for are functions that you needed to backport for PHP4 (Drupal 7 requires PHP 5.2), referer_uri(), time(), drupal_clone(), etc.

Be sure to mark anything you've identified

If you have found any other ways to help being porting your Drupal 6 module, please add a comment and I'll add it to the list!