| [ Index ] |
PHP Cross Reference of Drupal 6 (yi-drupal) |
[Source view] [Print] [Project Stats]
(no description)
| File Size: | 2727 lines (114 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
| hook_action_info() X-Ref |
| Declare information about one or more Drupal actions. Any module can define any number of Drupal actions. The trigger module is an example of a module that uses actions. An action consists of two or three parts: (1) an action definition (returned by this hook), (2) a function which does the action (which by convention is named module + '_' + description of what the function does + '_action'), and an optional form definition function that defines a configuration form (which has the name of the action with '_form' appended to it.) return: |
| hook_actions_delete($aid) X-Ref |
| Execute code after an action is deleted. param: $aid |
| hook_action_info_alter(&$actions) X-Ref |
| Alter the actions declared by another module. Called by actions_list() to allow modules to alter the return values from implementations of hook_action_info(). |
| hook_block($op = 'list', $delta = 0, $edit = array() X-Ref |
| Declare a block or set of blocks. Any module can declare a block (or blocks) to be displayed by implementing hook_block(), which also allows you to specify any custom configuration settings, and how to display the block. In hook_block(), each block your module provides is given a unique identifier referred to as "delta" (the array key in the return value for the 'list' operation). Delta values only need to be unique within your module, and they are used in the following ways: - Passed into the other hook_block() operations as an argument to identify the block being configured or viewed. - Used to construct the default HTML ID of "block-MODULE-DELTA" applied to each block when it is rendered (which can then be used for CSS styling or JavaScript programming). - Used to define a theming template suggestion of block__MODULE__DELTA, for advanced theming possibilities. The values of delta can be strings or numbers, but because of the uses above it is preferable to use descriptive strings whenever possible, and only use a numeric identifier if you have to (for instance if your module allows users to create several similar blocks that you identify within your module code with numeric IDs). param: $op param: $delta param: $edit return: |
| hook_comment(&$a1, $op) X-Ref |
| Respond to comment actions. This hook allows modules to extend the comments system by responding when certain actions take place. param: $a1 param: $op |
| hook_cron() X-Ref |
| Perform periodic actions. Modules that require to schedule some commands to be executed at regular intervals can implement hook_cron(). The engine will then call the hook at the appropriate intervals defined by the administrator. This interface is particularly handy to implement timers or to automate certain tasks. Database maintenance, recalculation of settings or parameters, and automatic mailings are good candidates for cron tasks. return: |
| hook_hook_info() X-Ref |
| Expose a list of triggers (events) that users can assign actions to. return: |
| hook_menu_alter(&$items) X-Ref |
| Alter the data being saved to the {menu_router} table after hook_menu is invoked. This hook is invoked by menu_router_build(). The menu definitions are passed in by reference. Each element of the $items array is one item returned by a module from hook_menu. Additional items may be added, or existing items altered. param: $items return: |
| hook_menu_link_alter(&$item, $menu) X-Ref |
| Alter the data being saved to the {menu_links} table by menu_link_save(). param: $item param: $menu return: |
| hook_translated_menu_link_alter(&$item, $map) X-Ref |
| Alter a menu link after it's translated, but before it's rendered. This hook may be used, for example, to add a page-specific query string. For performance reasons, only links that have $item['options']['alter'] == TRUE will be passed into this hook. The $item['options']['alter'] flag should generally be set using hook_menu_link_alter(). param: $item param: $map return: |
| hook_db_rewrite_sql($query, $primary_table, $primary_field, $args) X-Ref |
| Rewrite database queries, usually for access control. Add JOIN and WHERE statements to queries and decide whether the primary_field shall be made DISTINCT. For node objects, primary field is always called nid. For taxonomy terms, it is tid and for vocabularies it is vid. For comments, it is cid. Primary table is the table where the primary object (node, file, term_node etc.) is. You shall return an associative array. Possible keys are 'join', 'where' and 'distinct'. The value of 'distinct' shall be 1 if you want that the primary_field made DISTINCT. param: $query param: $primary_table param: $primary_field param: $args return: |
| hook_elements() X-Ref |
| Allows modules to declare their own Forms API element types and specify their default values. This hook allows modules to declare their own form element types and to specify their default values. The values returned by this hook will be merged with the elements returned by hook_form() implementations and so can return defaults for any Form APIs keys in addition to those explicitly mentioned below. Each of the form element types defined by this hook is assumed to have a matching theme function, e.g. theme_elementtype(), which should be registered with hook_theme() as normal. For more information about custom element types see the explanation at return: |
| hook_exit($destination = NULL) X-Ref |
| Perform cleanup tasks. This hook is run at the end of each page request. It is often used for page logging and printing out debugging information. Only use this hook if your code must run even for cached page views. If you have code which must run once on all non cached pages, use hook_init instead. Thats the usual case. If you implement this hook and see an error like 'Call to undefined function', it is likely that you are depending on the presence of a module which has not been loaded yet. It is not loaded because Drupal is still in bootstrap mode. param: $destination return: |
| hook_file_download($filepath) X-Ref |
| Control access to private file downloads and specify HTTP headers. This hook allows modules enforce permissions on file downloads when the private file download method is selected. Modules can also provide headers to specify information like the file's name or MIME type. param: $filepath return: |
| hook_filter($op, $delta = 0, $format = -1, $text = '', $cache_id = 0) X-Ref |
| Define content filters. Content in Drupal is passed through all enabled filters before it is output. This lets a module modify content to the site administrator's liking. This hook contains all that is needed for having a module provide filtering functionality. Depending on $op, different tasks are performed. A module can contain as many filters as it wants. The 'list' operation tells the filter system which filters are available. Every filter has a numerical 'delta' which is used to refer to it in every operation. Filtering is a two-step process. First, the content is 'prepared' by calling the 'prepare' operation for every filter. The purpose of 'prepare' is to escape HTML-like structures. For example, imagine a filter which allows the user to paste entire chunks of programming code without requiring manual escaping of special HTML characters like @< or @&. If the programming code were left untouched, then other filters could think it was HTML and change it. For most filters however, the prepare-step is not necessary, and they can just return the input without changes. Filters should not use the 'prepare' step for anything other than escaping, because that would short-circuits the control the user has over the order in which filters are applied. The second step is the actual processing step. The result from the prepare-step gets passed to all the filters again, this time with the 'process' operation. It's here that filters should perform actual changing of the content: transforming URLs into hyperlinks, converting smileys into images, etc. An important aspect of the filtering system are 'input formats'. Every input format is an entire filter setup: which filters to enable, in what order and with what settings. Filters that provide settings should usually store these settings per format. If the filter's behaviour depends on an extensive list and/or external data (e.g. a list of smileys, a list of glossary terms) then filters are allowed to provide a separate, global configuration page rather than provide settings per format. In that case, there should be a link from the format-specific settings to the separate settings page. For performance reasons content is only filtered once; the result is stored in the cache table and retrieved the next time the piece of content is displayed. If a filter's output is dynamic it can override the cache mechanism, but obviously this feature should be used with caution: having one 'no cache' filter in a particular input format disables caching for the entire format, not just for one filter. Beware of the filter cache when developing your module: it is advised to set your filter to 'no cache' while developing, but be sure to remove it again if it's not needed. You can clear the cache by running the SQL query 'DELETE FROM cache_filter'; param: $op param: $delta param: $format param: $text param: $cache_id return: |
| hook_filter_tips($delta, $format, $long = FALSE) X-Ref |
| Provide tips for using filters. A module's tips should be informative and to the point. Short tips are preferably one-liners. param: $delta param: $format param: $long return: |
| hook_footer($main = 0) X-Ref |
| Insert closing HTML. This hook enables modules to insert HTML just before the \</body\> closing tag of web pages. This is useful for adding JavaScript code to the footer and for outputting debug information. It is not possible to add JavaScript to the header at this point, and developers wishing to do so should use hook_init() instead. param: $main return: |
| hook_schema_alter(&$schema) X-Ref |
| Performs alterations to existing database schemas. When a module modifies the database structure of another module (by changing, adding or removing fields, keys or indexes), it should implement hook_schema_alter() to update the default $schema to take its changes into account. See hook_schema() for details on the schema definition structure. param: $schema return: |
| hook_form_alter(&$form, &$form_state, $form_id) X-Ref |
| Perform alterations before a form is rendered. One popular use of this hook is to add form elements to the node form. When altering a node form, the node object retrieved at from $form['#node']. Note that instead of hook_form_alter(), which is called for all forms, you can also use hook_form_FORM_ID_alter() to alter a specific form. param: $form param: $form_state param: $form_id |
| hook_form_FORM_ID_alter(&$form, &$form_state) X-Ref |
| Provide a form-specific alteration instead of the global hook_form_alter(). Modules can implement hook_form_FORM_ID_alter() to modify a specific form, rather than implementing hook_form_alter() and checking the form ID, or using long switch statements to alter multiple forms. Note that this hook fires before hook_form_alter(). Therefore all implementations of hook_form_FORM_ID_alter() will run before all implementations of hook_form_alter(), regardless of the module order. param: $form param: $form_state |
| hook_forms($form_id, $args) X-Ref |
| Map form_ids to builder functions. This hook allows modules to build multiple forms from a single form "factory" function but each form will have a different form id for submission, validation, theming or alteration by other modules. The callback arguments will be passed as parameters to the function. Callers of drupal_get_form() are also able to pass in parameters. These will be appended after those specified by hook_forms(). See node_forms() for an actual example of how multiple forms share a common building function. param: $form_id param: $args return: |
| hook_help($path, $arg) X-Ref |
| Provide online user help. By implementing hook_help(), a module can make documentation available to the user for the module as a whole, or for specific paths. Help for developers should usually be provided via function header comments in the code, or in special API example files. For a detailed usage example, see page_example.module. param: $path param: $arg return: |
| page_cache_fastpath() X-Ref |
| Outputs a cached page. By implementing page_cache_fastpath(), a special cache handler can skip most of the bootstrap process, including the database connection. This function is invoked during DRUPAL_BOOTSTRAP_EARLY_PAGE_CACHE. return: |
| hook_boot() X-Ref |
| Perform setup tasks. See also, hook_init. This hook is run at the beginning of the page request. It is typically used to set up global parameters which are needed later in the request. Only use this hook if your code must run even for cached page views.This hook is called before modules or most include files are loaded into memory. It happens while Drupal is still in bootstrap mode. return: |
| hook_init() X-Ref |
| Perform setup tasks. See also, hook_boot. This hook is run at the beginning of the page request. It is typically used to set up global parameters which are needed later in the request. when this hook is called, all modules are already loaded in memory. For example, this hook is a typical place for modules to add CSS or JS that should be present on every page. This hook is not run on cached pages - though CSS or JS added this way will be present on a cached page. return: |
| hook_link($type, $object, $teaser = FALSE) X-Ref |
| Define internal Drupal links. This hook enables modules to add links to many parts of Drupal. Links may be added in nodes or in the navigation block, for example. The returned array should be a keyed array of link entries. Each link can be in one of two formats. The first format will use the l() function to render the link: - attributes: Optional. See l() for usage. - fragment: Optional. See l() for usage. - href: Required. The URL of the link. - html: Optional. See l() for usage. - query: Optional. See l() for usage. - title: Required. The name of the link. The second format can be used for non-links. Leaving out the href index will select this format: - title: Required. The text or HTML code to display. - attributes: Optional. An associative array of HTML attributes to apply to the span tag. - html: Optional. If not set to true, check_plain() will be run on the title before it is displayed. param: $type param: $object param: $teaser return: |
| hook_link_alter(&$links, $node, $comment = NULL) X-Ref |
| Perform alterations before links on a node or comment are rendered. One popular use of this hook is to modify/remove links from other modules. If you want to add a link to the links section of a node or comment, use hook_link() instead. param: $links param: $node param: $comment |
| hook_profile_alter(&$account) X-Ref |
| Alter profile items before they are rendered. You may omit/add/re-sort/re-categorize, etc. param: $account |
| hook_mail_alter(&$message) X-Ref |
| Alter any aspect of email sent by Drupal. You can use this hook to add a common site footer to all outgoing email, add extra header fields, and/or modify the email in any way. HTML-izing the outgoing email is one possibility. See also drupal_mail(). param: $message |
| hook_menu() X-Ref |
| Define menu items and page callbacks. This hook enables modules to register paths in order to define how URL requests are handled. Paths may be registered for URL handling only, or they can register a link to be placed in a menu (usually the Navigation menu). A path and its associated information is commonly called a "menu router item". This hook is rarely called (for example, when modules are enabled), and its results are cached in the database. hook_menu() implementations return an associative array whose keys define paths and whose values are an associative array of properties for each path. (The complete list of properties is in the return value section below.) The definition for each path may include a page callback function, which is invoked when the registered path is requested. If there is no other registered path that fits the requested path better, any further path components are passed to the callback function. For example, your module could register path 'abc/def': return: |
| hook_system_info_alter(&$info, $file) X-Ref |
| Alter the information parsed from module and theme .info files This hook is invoked in module_rebuild_cache() and in system_theme_data(). A module may implement this hook in order to add to or alter the data generated by reading the .info file with drupal_parse_info_file(). param: &$info param: $file |
| hook_update_status_alter(&$projects) X-Ref |
| Alter the information about available updates for projects. param: $projects |
| hook_update_projects_alter(&$projects) X-Ref |
| Alter the list of projects before fetching data and comparing versions. Most modules will never need to implement this hook. It is for advanced interaction with the update status module: mere mortals need not apply. The primary use-case for this hook is to add projects to the list, for example, to provide update status data on disabled modules and themes. A contributed module might want to hide projects from the list, for example, if there is a site-specific module that doesn't have any official releases, that module could remove itself from this list to avoid "No available releases found" warnings on the available updates report. In rare cases, a module might want to alter the data associated with a project already in the list. param: $projects |
| hook_node_grants($account, $op) X-Ref |
| Inform the node access system what permissions the user has. This hook is for implementation by node access modules. In this hook, the module grants a user different "grant IDs" within one or more "realms". In hook_node_access_records(), the realms and grant IDs are associated with permission to view, edit, and delete individual nodes. The realms and grant IDs can be arbitrarily defined by your node access module; it is common to use role IDs as grant IDs, but that is not required. Your module could instead maintain its own list of users, where each list has an ID. In that case, the return value of this hook would be an array of the list IDs that this user is a member of. A node access module may implement as many realms as necessary to properly define the access privileges for the nodes. param: $account param: $op return: |
| hook_node_access_records($node) X-Ref |
| Set permissions for a node to be written to the database. When a node is saved, a module implementing hook_node_access_records() will be asked if it is interested in the access permissions for a node. If it is interested, it must respond with an array of permissions arrays for that node. Each permissions item in the array is an array with the following elements: - 'realm': The name of a realm that the module has defined in hook_node_grants(). - 'gid': A 'grant ID' from hook_node_grants(). - 'grant_view': If set to TRUE a user that has been identified as a member of this gid within this realm can view this node. - 'grant_update': If set to TRUE a user that has been identified as a member of this gid within this realm can edit this node. - 'grant_delete': If set to TRUE a user that has been identified as a member of this gid within this realm can delete this node. - 'priority': If multiple modules seek to set permissions on a node, the realms that have the highest priority will win out, and realms with a lower priority will not be written. If there is any doubt, it is best to leave this 0. |
| hook_node_operations() X-Ref |
| Add mass node operations. This hook enables modules to inject custom operations into the mass operations dropdown found at admin/content/node, by associating a callback function with the operation, which is called when the form is submitted. The callback function receives one initial argument, which is an array of the checked nodes. return: |
| hook_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) X-Ref |
| Act on nodes defined by other modules. Despite what its name might make you think, hook_nodeapi() is not reserved for node modules. On the contrary, it allows modules to react to actions affecting all kinds of nodes, regardless of whether that module defined the node. It is common to find hook_nodeapi() used in conjunction with hook_form_alter(). Modules use hook_form_alter() to place additional form elements onto the node edit form, and hook_nodeapi() is used to read and write those values to and from the database. param: &$node param: $op param: $a3 param: $a4 return: |
| hook_openid($op, $request) X-Ref |
| Allow modules to modify the OpenID request parameters. param: $op param: $request return: |
| hook_perm() X-Ref |
| Define user permissions. This hook can supply permissions that the module defines, so that they can be selected on the user permissions page and used to grant or restrict access to actions the module performs. Permissions are checked using user_access(). For a detailed usage example, see page_example.module. return: |
| hook_ping($name = '', $url = '') X-Ref |
| Ping another server. This hook allows a module to notify other sites of updates on your Drupal site. param: $name param: $url return: |
| hook_search($op = 'search', $keys = NULL) X-Ref |
| Define a custom search routine. This hook allows a module to perform searches on content it defines (custom node types, users, or comments, for example) when a site search is performed. Note that you can use form API to extend the search. You will need to use hook_form_alter() to add any additional required form elements. You can process their values on submission using a custom validation function. You will need to merge any custom search values into the search keys using a key:value syntax. This allows all search queries to have a clean and permanent URL. See node_form_alter() for an example. The example given here is for node.module, which uses the indexed search capabilities. To do this, node module also implements hook_update_index() which is used to create and maintain the index. We call do_search() with the keys, the module name, and extra SQL fragments to use when searching. See hook_update_index() for more information. param: $op param: $keys return: |
| hook_search_preprocess($text) X-Ref |
| Preprocess text for the search index. This hook is called both for text added to the search index, as well as the keywords users have submitted for searching. This is required for example to allow Japanese or Chinese text to be searched. As these languages do not use spaces, it needs to be split into separate words before it can be indexed. There are various external libraries for this. param: $text return: |
| hook_taxonomy($op, $type, $array = NULL) X-Ref |
| Act on taxonomy changes. This hook allows modules to take action when the terms and vocabularies in the taxonomy are modified. param: $op param: $type param: $array return: |
| hook_theme($existing, $type, $theme, $path) X-Ref |
| Register a module (or theme's) theme implementations. Modules and themes implementing this return an array of arrays. The key to each sub-array is the internal name of the hook, and the array contains info about the hook. Each array may contain the following items: - arguments: (required) An array of arguments that this theme hook uses. This value allows the theme layer to properly utilize templates. The array keys represent the name of the variable, and the value will be used as the default value if not specified to the theme() function. These arguments must be in the same order that they will be given to the theme() function. - file: The file the implementation resides in. This file will be included prior to the theme being rendered, to make sure that the function or preprocess function (as needed) is actually loaded; this makes it possible to split theme functions out into separate files quite easily. - path: Override the path of the file to be used. Ordinarily the module or theme path will be used, but if the file will not be in the default path, include it here. This path should be relative to the Drupal root directory. - template: If specified, this theme implementation is a template, and this is the template file without an extension. Do not put .tpl.php on this file; that extension will be added automatically by the default rendering engine (which is PHPTemplate). If 'path', above, is specified, the template should also be in this path. - function: If specified, this will be the function name to invoke for this implementation. If neither file nor function is specified, a default function name will be assumed. For example, if a module registers the 'node' theme hook, 'theme_node' will be assigned to its function. If the chameleon theme registers the node hook, it will be assigned 'chameleon_node' as its function. - pattern: A regular expression pattern to be used to allow this theme implementation to have a dynamic name. The convention is to use __ to differentiate the dynamic portion of the theme. For example, to allow forums to be themed individually, the pattern might be: 'forum__'. Then, when the forum is themed, call: theme(array('forum__'. $tid, 'forum'), $forum). - preprocess functions: A list of functions used to preprocess this data. Ordinarily this won't be used; it's automatically filled in. By default, for a module this will be filled in as template_preprocess_HOOK. For a theme this will be filled in as phptemplate_preprocess and phptemplate_preprocess_HOOK as well as themename_preprocess and themename_preprocess_HOOK. - override preprocess functions: Set to TRUE when a theme does NOT want the standard preprocess functions to run. This can be used to give a theme FULL control over how variables are set. For example, if a theme wants total control over how certain variables in the page.tpl.php are set, this can be set to true. Please keep in mind that when this is used by a theme, that theme becomes responsible for making sure necessary variables are set. - type: (automatically derived) Where the theme hook is defined: 'module', 'theme_engine', or 'theme'. - theme path: (automatically derived) The directory path of the theme or module, so that it doesn't need to be looked up. - theme paths: (automatically derived) An array of template suggestions where .tpl.php files related to this theme hook may be found. The following parameters are all optional. param: $existing param: $type param: $theme param: $path return: |
| hook_theme_registry_alter(&$theme_registry) X-Ref |
| Alter the theme registry information returned from hook_theme(). The theme registry stores information about all available theme hooks, including which callback functions those hooks will call when triggered, what template files are exposed by these hooks, and so on. Note that this hook is only executed as the theme cache is re-built. Changes here will not be visible until the next cache clear. The $theme_registry array is keyed by theme hook name, and contains the information returned from hook_theme(), as well as additional properties added by _theme_process_registry(). For example: param: $theme_registry |
| hook_update_index() X-Ref |
| Update Drupal's full-text index for this module. Modules can implement this hook if they want to use the full-text indexing mechanism in Drupal. This hook is called every cron run if search.module is enabled. A module should check which of its items were modified or added since the last run. It is advised that you implement a throttling mechanism which indexes at most 'search_cron_limit' items per run (see example below). You should also be aware that indexing may take too long and be aborted if there is a PHP time limit. That's why you should update your internal bookkeeping multiple times per run, preferably after every item that is indexed. Per item that needs to be indexed, you should call search_index() with its content as a single HTML string. The search indexer will analyse the HTML and use it to assign higher weights to important words (such as titles). It will also check for links that point to nodes, and use them to boost the ranking of the target nodes. |
| hook_user($op, &$edit, &$account, $category = NULL) X-Ref |
| Act on user account actions. This hook allows modules to react when operations are performed on user accounts. param: $op param: &$edit param: &$account param: $category return: |
| hook_user_operations() X-Ref |
| Add mass user operations. This hook enables modules to inject custom operations into the mass operations dropdown found at admin/user/user, by associating a callback function with the operation, which is called when the form is submitted. The callback function receives one initial argument, which is an array of the checked users. return: |
| hook_xmlrpc() X-Ref |
| Register XML-RPC callbacks. This hook lets a module register callback functions to be called when particular XML-RPC methods are invoked by a client. return: |
| hook_watchdog($log_entry) X-Ref |
| Log an event message This hook allows modules to route log events to custom destinations, such as SMS, Email, pager, syslog, ...etc. param: $log_entry return: |
| hook_mail($key, &$message, $params) X-Ref |
| Prepare a message based on parameters; called from drupal_mail(). param: $key param: $message param: $params |
| hook_flush_caches() X-Ref |
| Add a list of cache tables to be cleared. This hook allows your module to add cache table names to the list of cache tables that will be cleared by the Clear button on the Performance page or whenever drupal_flush_all_caches is invoked. param: None. return: |
| hook_term_path($term) X-Ref |
| Allows modules to provide an alternative path for the terms it manages. For vocabularies not maintained by taxonomy.module, give the maintaining module a chance to provide a path for terms in that vocabulary. "Not maintained by taxonomy.module" is misleading. It means that the vocabulary table contains a module name in the 'module' column. Any module may update this column and will then be called to provide an alternative path for the terms it recognizes (manages). This hook should be used rather than hard-coding a "taxonomy/term/xxx" path. param: $term return: |
| hook_locale($op = 'groups') X-Ref |
| Allows modules to define their own text groups that can be translated. param: $op |
| custom_url_rewrite_outbound(&$path, &$options, $original_path) X-Ref |
| custom_url_rewrite_outbound is not a hook, it's a function you can add to settings.php to alter all links generated by Drupal. This function is called from url(). This function is called very frequently (100+ times per page) so performance is critical. This function should change the value of $path and $options by reference. param: $path param: $options param: $original_path |
| custom_url_rewrite_inbound(&$result, $path, $path_language) X-Ref |
| custom_url_rewrite_inbound is not a hook, it's a function you can add to settings.php to alter incoming requests so they map to a Drupal path. This function is called before modules are loaded and the menu system is initialized and it changes $_GET['q']. This function should change the value of $result by reference. param: $result param: $path param: $path_language |
| hook_translation_link_alter(&$links, $path) X-Ref |
| Perform alterations on translation links. A translation link may need to point to a different path or use a translated link text before going through l(), which will just handle the path aliases. param: $links param: $path return: |
| Generated: Mon Jul 9 18:01:44 2012 | Cross-referenced by PHPXref 0.7 |