Blog

Recently we worked on a project to upgrade a website from Drupal 5 to Drupal 6. There were quite a few custom modules and we chose to take advantage of the deadwood, schema and coder modules, as described in this article . This sped up the conversion process, as the deadwood module made many changes on the original D5 code automatically and the coder module pointed us to places in the code that were incompatible with D6 and required modification.

Manual check and modification is still the most important part of this process, though these modules can often be a great help.

The following are some of the issues that we came across in the conversion process:

1) deadwood might automatically make an unwanted change

We found deadwood automatically converted a function some_prefix_access($node) in D5 to some_prefix_access($op, $node, $account) in D6. However, some_prefix was not the name of the current module and this function was not an implementation of hook_access. This automatic change was not desired.

2) coder might flag something correct as critical and thus suggest an inappropriate modification

In the code, drupal_get_form used the following callback function to display a form:

function some_prefix_form($form_state, $extra_arg) {
...
$form['op'] = array('#type' => 'submit', '#value' => t('Submit'));
...
return $form;
}

Coder module displayed such warnings:

Line xx: replace $form['op'] with $form_state['values']['op']
$form['op'] = array('#type' => 'submit', '#value' => t('Submit'));

There's no need to change $form['op'] to $form_state['values']['op'] here.

3) deadwood and coder might not see all issues in the code

We found an l() function inside a form remained unchanged in D6 (see http://api.drupal.org/api/function/l/6 for parameter changes in the function).

Deadwood was able to convert hook_access() function in a module, but it didn't do anything about the argument list of the module_invoke() function if it was used to invoke hook_access of that particular module, thus resulting in a missing argument warning.

4) Some functions required manual modifications anyway

For example,
In the og module, the function og_menu_check() in D5 (og 5.x-3.1) didn't exist in D6 (og 6.x-2.0); _og_user_mail_text() was changed to _og_mail_text(); relevant database table schema also changed.

Views 1 was used in our D5 and views 2 in D6; the ways to implement some views-related hooks were different in views 1 and 2.

In the privatemsg module, database table names and schemas were changed in D6.

So if these functions or database tables were used in the original code, manual changes were required.

To sum up, while deadwood, schema and coder modules can be a great help in the process of converting a site from D5 to D6, be aware that manual check, comparison and modification of the code is still an essential part.