API Methods Common to All Modules

Add these modules to the configuration; a handy way of assuring that modules whose presence your module depends on are really there. modids is an array of module identifiers as those used by Configuration->find_module(). Typical usage:

void start(int occasion, Configuration conf)
{
  module_dependencies(conf, ({ "graphics_text" }));
}

Optional callback for adding action buttons to the module's administration settings page; convenient for triggering module actions like flushing caches and the like.

The indices of the returned mapping are the action descriptions that will show up on each button (e.g. "flush cache"), and the corresponding values are the callbacks for each button respectively. These functions may take an optional RequestID argument, where this id object refers to the id object in the admin interface sent with the request used to invoke the action by the administrator.

Returns the internal mountpoint, where find_internal() is mounted.

Returns the internal mountpoint as an absolute path. This includes the site prefix, which is typically the empty string for a site mounted at a URL with no path component, such as "http://*/", as opposed to for example "http://*/roxen/2.1/", which would be prefixed "roxen/2.1/".

This method is recommended when you want to generate a link to your internal resources supplied by find_internal().

Set the name and optionally email address of the author of the module. Names on the format "author name <author_email>" will end up as links on the module's information page in the admin interface. In the case of multiple authors, an array of such strings can be passed to generate one link per author (the array order is preserved).

A common way of referring to a location where you maintain information about your module, or similar. The URL will turn up on the module's information page in the admin interface, referred to as the module's home page.