Last updated January 13, 2016. Created on December 24, 2008.
Edited by jeromewiley, milodesc, robin.vaughan, loopduplicate. Log in to edit this page.

Drupal 7 introduces a code registry - an inventory of all classes and interfaces for all enabled modules and Drupal's core files. The registry stores the path to the file that a given class or interface is defined in, and loads the file when necessary.

The registry loads classes and interfaces on demand, via php's built in class autoloading mechanism. This will cut down on the amount of code loaded per request, and reduce Drupal's memory footprint.

The only file unconditionally loaded by Drupal for a given module is module_name.module. Any code that must always be available without using the registry should be put in this file.

Include classes and interfaces by listing them with the files[] property in your .info file. See

All the files listed in .info files of currently enabled modules are parsed when modules are rebuilt (Only changed/new files in that list are added, for performance reasons).

The information is then stored in the {registry} and {registry_file} tables. The registry table in Drupal database holds the important information regarding the name of the Class/Interface or the function along with the name of module that had implemented and the complete file path within the Drupal set up that contains the Class or Interface or the function name also.

The registry is rebuilt when modules are enabled or disabled in order to incorporate new code or remove code from disabled modules. If you are developing new code with classes, make sure to rebuild the registry regularly so that new resources are incorporated. (Clearing all caches or calling registry_rebuild() directly both will do this.) Rebuilding an existing registry to incorporate new changes is not that expensive, as the registry will not reparse files that have the same path and modification time as the last build.

Under certain conditions a stale file registry can lead to errors that block access to a site. The Registry rebuild project provides tools to help address this problem.

Note Files that do not contain classes and interfaces that might be put into use at any time by your module file do not need to be listed with the files[] property in your .info file. Instead, such code can continue to be loaded when you need it, such as through the hook_menu()'s file property. If your module introduces hooks of its own, consider implementing hook_hook_info() to allow other modules' hook implementations to be autoloaded.

Looking for support? Visit the forums, or join #drupal-support in IRC.


EvanDonovan’s picture

I think this needs to be updated to reflect that the registry is only for classes now. But I don't know the best practices, so I'll refrain.

Nonprofit / EdTech Mentor

jhodgdon’s picture

I think it was totally scrapped, so probably this page should be archived/deleted.

pwolanin’s picture

no, there is still a that stores the names of all classes and interfaces for autoloading.

Work: Acquia

EvanDonovan’s picture

I think the 4th paragraph is bumped to D8/never though, so that should be axed at least.

Nonprofit / EdTech Mentor

loopduplicate’s picture

This page is accurate now. There have been a handful of updates to it since the last comments have been made.