For the correct functioning, some modules require regular technical maintenance. For example, watchdog module needs to remove old messages and search module needs to index site content.

Here is the list of core modules using cron

• aggregator.module
• drupal.module
• node.module
• ping.module
• poll.module
• search.module
• statistics.module
• watchdog.module

Here is the short list of external modules using cron

• db_maintenance.module
• freemind.module
• privatemsg.module
• image.module
• simplenews.module
• votingapi.module

Make this actions manually becomes too much a sap.

Alternatives

• Actions in Drupal 6
• Crontab (cron)

cron

Cron is necessary to regularly make some actions. Unix systems have a special service – cron, that is used for recurrent tasks implementation at specified time moment.

You can set time very flexible. For example, every 11 minutes, on every 11 minute, at 6.11 pm every day, every week, one time a month, etc.

This system service call script  /cron.php to Drupal. But you should specify path to cron.php (full path, not URL) in the settings of hosting.

Drupal uses system cron for performing a set of service operations (for example, search indexing) regardless of visitors’ requests to a site.

Cron.php page call is placed in crontab with the required periodicity.
Some hostings can disable using of cron for users. In this case poormanscron would help. It performs cron tasks in Drupal without using system cron.

Actions in Drupal 6

An action is a function that operates like a stored procedure. The function’s parameters, if any, are stored in the database and the function is executed by retrieving these stored parameters and calling the function.

Actions are usually used to configure Drupal’s response to an event. For example, suppose a Drupal site administrator wants to be notified by email whenever a new user signs up. She would configure a "Send email" action and use the trigger module to assign that action to execute when a new user joins the site. (Technically, that would be when the user hook’s ‘insert’ op runs.)

The actions engine, which executes actions, lives in includes/actions.inc. The dispatcher for actions is in modules/trigger.module.

The configuration screens for adding, removing, and configuring individual actions are part of system.module.

The interface for assigning actions to events (that is, hooks) is provided by modules/trigger.module.

The hook that describes actions (hook_actions_info()) and the actions themselves live in individual modules. Actions that affect nodes, like the "Publish node" action, live in node.module.

There are two steps to create a new action. First, we must describe the action to Drupal using hook_action_info(). Then, we must actually write the code that will be executed.