Converting 6.x modules to 7.x

Overview of Drupal API changes in 7.x

1. Permissions are required to have descriptions
2. _comment_load() is now comment_load()
3. Module .info files must now specify all loadable code files explicitly.
4. The hook_menu() "file" and "file path" keys have been removed.
5. New permission tables.

Permissions are required to have descriptions

(issue) In the implementation of hook_perm(), the returned array must be in the following format:

Previously, the values were the permission names; now permission names are the keys and the corresponding value is the permission description.

_comment_load() is now comment_load()

(issue) _comment_load() was renamed to comment_load() as it is an external-facing API function.

In addition to the function name itself, any menu items that are using the %_comment wildcard will need to change to %comment.

Module .info files must now specify all loadable code files explicitly.

(issue) Drupal now supports a dynamic-loading code registry. To support it, all modules must now declare their code files in the .info file like so:

When a module is enabled, Drupal will rescan all declared files and index all functions and classes it finds. That means any class or function that is to be called indirectly (such as a hook) can live outside the .module file, and it will be included on-demand. Classes will be loaded automatically by PHP when they are first accessed. For functions, replace all calls to function_exists() with drupal_function_exists(), which will load the necessary file and return TRUE or FALSE depending on whether the function now exists. In the case of hooks or any code called via module_invoke*(), node_invoke(), etc. that will be done automatically.

The hook_menu() "file" and "file path" keys have been removed.

In Drupal 6, menu items could declare an include file to be loaded on-demand for that page request. In Drupal 7, that is no longer necessary as such files will be loaded automatically by the registry. The file and file path entries should be removed.

New permission tables.

(Issue) The {permission} table is gone, instead we have a {role_permission} which stores (role ID, permission string) pairs. Thus, each permission granted for a given role ID is a separate row in the table. This update is in system.install so that it will already be complete when any other core or contributed module update is running. This should make any alteration of existing permissions much easier.