| [ Index ] |
PHP Cross Reference of Drupal 6 (yi-drupal) |
[Source view] [Print] [Project Stats]
(no description)
| File Size: | 352 lines (13 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
| hook_requirements($phase) X-Ref |
| Check installation requirements and do status reporting. This hook has two closely related uses, determined by the $phase argument: checking installation requirements ($phase == 'install') and status reporting ($phase == 'runtime'). Note that this hook, like all others dealing with installation and updates, must reside in a module_name.install file, or it will not properly abort the installation of the module if a critical requirement is missing. During the 'install' phase, modules can for example assert that library or server versions are available or sufficient. Note that the installation of a module can happen during installation of Drupal itself (by install.php) with an installation profile or later by hand. As a consequence, install-time requirements must be checked without access to the full Drupal API, because it is not available during install.php. For localisation you should for example use $t = get_t() to retrieve the appropriate localisation function name (t() or st()). If a requirement has a severity of REQUIREMENT_ERROR, install.php will abort or at least the module will not install. Other severity levels have no effect on the installation. Module dependencies do not belong to these installation requirements, but should be defined in the module's .info file. The 'runtime' phase is not limited to pure installation requirements but can also be used for more general status information like maintenance tasks and security issues. The returned 'requirements' will be listed on the status report in the administration section, with indication of the severity level. Moreover, any requirement with a severity of REQUIREMENT_ERROR severity will result in a notice on the the administration overview page. param: $phase return: |
| hook_schema() X-Ref |
| Define the current version of the database schema. A Drupal schema definition is an array structure representing one or more tables and their related keys and indexes. A schema is defined by hook_schema() which must live in your module's .install file. By implementing hook_schema() and specifying the tables your module declares, you can easily create and drop these tables on all supported database engines. You don't have to deal with the different SQL dialects for table creation and alteration of the supported database engines. See the Schema API documentation at http://drupal.org/node/146843 for details on hook_schema(), where database tables are defined. return: |
| hook_install() X-Ref |
| Install the current version of the database schema, and any other setup tasks. The hook will be called the first time a module is installed, and the module's schema version will be set to the module's greatest numbered update hook. Because of this, anytime a hook_update_N() is added to the module, this function needs to be updated to reflect the current version of the database schema. See the Schema API documentation at http://drupal.org/node/146843 for details on hook_schema, where a database tables are defined. Note that functions declared in the module being installed are not yet available. The implementation of hook_install() will need to explicitly load the module before any declared functions may be invoked. Anything added or modified in this function that can be removed during uninstall should be removed with hook_uninstall(). |
| hook_update_N(&$sandbox) X-Ref |
| Perform a single update. For each patch which requires a database change add a new hook_update_N() which will be called by update.php. The database updates are numbered sequentially according to the version of Drupal you are compatible with. Schema updates should adhere to the Schema API: http://drupal.org/node/150215 Database updates consist of 3 parts: - 1 digit for Drupal core compatibility - 1 digit for your module's major release version (e.g. is this the 5.x-1.* (1) or 5.x-2.* (2) series of your module?) - 2 digits for sequential counting starting with 00 The 2nd digit should be 0 for initial porting of your module to a new Drupal core API. Examples: - mymodule_update_5200() - This is the first update to get the database ready to run mymodule 5.x-2.*. - mymodule_update_6000() - This is the required update for mymodule to run with Drupal core API 6.x. - mymodule_update_6100() - This is the first update to get the database ready to run mymodule 6.x-1.*. - mymodule_update_6200() - This is the first update to get the database ready to run mymodule 6.x-2.*. Users can directly update from 5.x-2.* to 6.x-2.* and they get all 60XX and 62XX updates, but not 61XX updates, because those reside in the 6.x-1.x branch only. A good rule of thumb is to remove updates older than two major releases of Drupal. See hook_update_last_removed() to notify Drupal about the removals. Never renumber update functions. Further information about releases and release numbers: - http://drupal.org/handbook/version-info - http://drupal.org/node/93999 (Overview of contributions branches and tags) - http://drupal.org/handbook/cvs/releases Implementations of this hook should be placed in a mymodule.install file in the same directory as mymodule.module. Drupal core's updates are implemented using the system module as a name and stored in database/updates.inc. return: An array with the results of the calls to update_sql(). An update |
| hook_uninstall() X-Ref |
| Remove any information that the module sets. The information that the module should remove includes: - Variables that the module has set using variable_set(). - Modifications to existing tables. - Database tables the module created. The uninstall hook will fire when the module gets uninstalled. |
| hook_update_last_removed() X-Ref |
| Return a number which is no longer available as hook_update_N(). If you remove some update functions from your mymodule.install file, you should notify Drupal of those missing functions. This way, Drupal can ensure that no update is accidentally skipped. Implementations of this hook should be placed in a mymodule.install file in the same directory as mymodule.module. return: |
| hook_enable() X-Ref |
| Perform necessary actions after module is enabled. The hook is called everytime module is enabled. |
| hook_disable() X-Ref |
| Perform necessary actions before module is disabled. The hook is called everytime module is disabled. |
| Generated: Mon Jul 9 18:01:44 2012 | Cross-referenced by PHPXref 0.7 |