Drupal is a truly modular framework. Functionality is included in modules, which can be enabled or disabled (some required modules cannot be disabled). Features are added to a Drupal web site by enabling existing modules, installing modules written by members of the Drupal community, or writing new modules. In this way, web sites that do not need certain features can run lean and mean, while those that need more can add as much functionality as desired. This is shown in Figure 1-3.
Both the addition of new content types such as recipes, blog posts, or files, and the addition of new behaviors such as e-mail notification, peer-to-peer publishing, and aggregation are handled through modules. Drupal makes use of the inversion of control design pattern, in which modular functionality is called by the framework at the appropriate time. These opportunities for modules to do their thing are called hooks.
Hooks can be thought of as internal Drupal events. They are also called callbacks, though because they are constructed by function naming conventions and not by registering with a listener, they are not truly being called back. Hooks allow modules to "hook into" what is happening in the rest of Drupal.
Suppose a user logs into your Drupal web site. At the time the user logs in, Drupal fires the user hook. That means that any function named according to the convention module name plus hook name will be called. For example, comment_user() in the comment module, locale_user() in the locale module, node_user() in the node module, and any other similarly named functions will be called. If you were to write a custom module called "spammy.module" and include a function called "spammy_user()" that sent an e-mail to the user, your function would be called too, and the hapless user would receive an unsolicited e-mail at every login.
The most common way to tap into Drupal's core functionality is through the implementation of hooks in modules.