0, * 'gid' => 888, * 'realm' => 'example_realm', * 'grant_view' => 1, * 'grant_update' => 0, * 'grant_delete' => 0, * ); * drupal_write_record('node_access', $record); * @endcode * And then in its hook_node_grants() implementation, it would need to return: * @code * if ($op == 'view') { * $grants['example_realm'] = array(888); * } * @endcode * If you decide to do this, be aware that the node_access_rebuild() function * will erase any node ID 0 entry when it is called, so you will need to make * sure to restore your {node_access} record after node_access_rebuild() is * called. * * @see node_access_view_all_nodes() * @see node_access_rebuild() * * @param $account * The user object whose grants are requested. * @param $op * The node operation to be performed, such as 'view', 'update', or 'delete'. * * @return * An array whose keys are "realms" of grants, and whose values are arrays of * the grant IDs within this realm that this user is being granted. * * For a detailed example, see node_access_example.module. * * @ingroup node_access */ function hook_node_grants($account, $op) { if (user_access('access private content', $account)) { $grants['example'] = array(1); } $grants['example_owner'] = array($account->uid); return $grants; } /** * 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. * * Node access grants apply regardless of the published or unpublished status * of the node. Implementations must make sure not to grant access to * unpublished nodes if they don't want to change the standard access control * behavior. Your module may need to create a separate access realm to handle * access to unpublished nodes. * * Note that the grant values in the return value from your hook must be * integers and not boolean TRUE and FALSE. * * 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 1 a user that has been identified as a member * of this gid within this realm can view this node. This should usually be * set to $node->status. Failure to do so may expose unpublished content * to some users. * - 'grant_update': If set to 1 a user that has been identified as a member * of this gid within this realm can edit this node. * - 'grant_delete': If set to 1 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. * * * When an implementation is interested in a node but want to deny access to * everyone, it may return a "deny all" grant: * * @code * $grants[] = array( * 'realm' => 'all', * 'gid' => 0, * 'grant_view' => 0, * 'grant_update' => 0, * 'grant_delete' => 0, * 'priority' => 1, * ); * @endcode * * Setting the priority should cancel out other grants. In the case of a * conflict between modules, it is safer to use hook_node_access_records_alter() * to return only the deny grant. * * Note: a deny all grant is not written to the database; denies are implicit. * * @see node_access_write_grants() * * @param $node * The node that has just been saved. * * @return * An array of grants as defined above. * * @see hook_node_access_records_alter() * @ingroup node_access */ function hook_node_access_records($node) { // We only care about the node if it has been marked private. If not, it is // treated just like any other node and we completely ignore it. if ($node->private) { $grants = array(); // Only published nodes should be viewable to all users. If we allow access // blindly here, then all users could view an unpublished node. if ($node->status) { $grants[] = array( 'realm' => 'example', 'gid' => 1, 'grant_view' => 1, 'grant_update' => 0, 'grant_delete' => 0, 'priority' => 0, ); } // For the example_author array, the GID is equivalent to a UID, which // means there are many groups of just 1 user. // Note that an author can always view his or her nodes, even if they // have status unpublished. $grants[] = array( 'realm' => 'example_author', 'gid' => $node->uid, 'grant_view' => 1, 'grant_update' => 1, 'grant_delete' => 1, 'priority' => 0, ); return $grants; } } /** * Alter permissions for a node before it is written to the database. * * Node access modules establish rules for user access to content. Node access * records are stored in the {node_access} table and define which permissions * are required to access a node. This hook is invoked after node access modules * returned their requirements via hook_node_access_records(); doing so allows * modules to modify the $grants array by reference before it is stored, so * custom or advanced business logic can be applied. * * @see hook_node_access_records() * * Upon viewing, editing or deleting a node, hook_node_grants() builds a * permissions array that is compared against the stored access records. The * user must have one or more matching permissions in order to complete the * requested operation. * * A module may deny all access to a node by setting $grants to an empty array. * * @see hook_node_grants() * @see hook_node_grants_alter() * * @param $grants * The $grants array returned by hook_node_access_records(). * @param $node * The node for which the grants were acquired. * * The preferred use of this hook is in a module that bridges multiple node * access modules with a configurable behavior, as shown in the example with the * 'is_preview' field. * * @ingroup node_access */ function hook_node_access_records_alter(&$grants, $node) { // Our module allows editors to mark specific articles with the 'is_preview' // field. If the node being saved has a TRUE value for that field, then only // our grants are retained, and other grants are removed. Doing so ensures // that our rules are enforced no matter what priority other grants are given. if ($node->is_preview) { // Our module grants are set in $grants['example']. $temp = $grants['example']; // Now remove all module grants but our own. $grants = array('example' => $temp); } } /** * Alter user access rules when trying to view, edit or delete a node. * * Node access modules establish rules for user access to content. * hook_node_grants() defines permissions for a user to view, edit or delete * nodes by building a $grants array that indicates the permissions assigned to * the user by each node access module. This hook is called to allow modules to * modify the $grants array by reference, so the interaction of multiple node * access modules can be altered or advanced business logic can be applied. * * @see hook_node_grants() * * The resulting grants are then checked against the records stored in the * {node_access} table to determine if the operation may be completed. * * A module may deny all access to a user by setting $grants to an empty array. * * @see hook_node_access_records() * @see hook_node_access_records_alter() * * @param $grants * The $grants array returned by hook_node_grants(). * @param $account * The user account requesting access to content. * @param $op * The operation being performed, 'view', 'update' or 'delete'. * * Developers may use this hook to either add additional grants to a user or to * remove existing grants. These rules are typically based on either the * permissions assigned to a user role, or specific attributes of a user * account. * * @ingroup node_access */ function hook_node_grants_alter(&$grants, $account, $op) { // Our sample module never allows certain roles to edit or delete // content. Since some other node access modules might allow this // permission, we expressly remove it by returning an empty $grants // array for roles specified in our variable setting. // Get our list of banned roles. $restricted = variable_get('example_restricted_roles', array()); if ($op != 'view' && !empty($restricted)) { // Now check the roles for this account against the restrictions. foreach ($restricted as $role_id) { if (isset($account->roles[$role_id])) { $grants = array(); } } } } /** * Add mass node operations. * * This hook enables modules to inject custom operations into the mass * operations dropdown found at admin/content, 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 * An array of operations. Each operation is an associative array that may * contain the following key-value pairs: * - label: (required) The label for the operation, displayed in the dropdown * menu. * - callback: (required) The function to call for the operation. * - callback arguments: (optional) An array of additional arguments to pass * to the callback function. */ function hook_node_operations() { $operations = array( 'publish' => array( 'label' => t('Publish selected content'), 'callback' => 'node_mass_update', 'callback arguments' => array('updates' => array('status' => NODE_PUBLISHED)), ), 'unpublish' => array( 'label' => t('Unpublish selected content'), 'callback' => 'node_mass_update', 'callback arguments' => array('updates' => array('status' => NODE_NOT_PUBLISHED)), ), 'promote' => array( 'label' => t('Promote selected content to front page'), 'callback' => 'node_mass_update', 'callback arguments' => array('updates' => array('status' => NODE_PUBLISHED, 'promote' => NODE_PROMOTED)), ), 'demote' => array( 'label' => t('Demote selected content from front page'), 'callback' => 'node_mass_update', 'callback arguments' => array('updates' => array('promote' => NODE_NOT_PROMOTED)), ), 'sticky' => array( 'label' => t('Make selected content sticky'), 'callback' => 'node_mass_update', 'callback arguments' => array('updates' => array('status' => NODE_PUBLISHED, 'sticky' => NODE_STICKY)), ), 'unsticky' => array( 'label' => t('Make selected content not sticky'), 'callback' => 'node_mass_update', 'callback arguments' => array('updates' => array('sticky' => NODE_NOT_STICKY)), ), 'delete' => array( 'label' => t('Delete selected content'), 'callback' => NULL, ), ); return $operations; } /** * Respond to node deletion. * * This hook is invoked from node_delete_multiple() after the type-specific * hook_delete() has been invoked, but before hook_entity_delete and * field_attach_delete() are called, and before the node is removed from the * node table in the database. * * @param $node * The node that is being deleted. * * @ingroup node_api_hooks */ function hook_node_delete($node) { db_delete('mytable') ->condition('nid', $node->nid) ->execute(); } /** * Respond to deletion of a node revision. * * This hook is invoked from node_revision_delete() after the revision has been * removed from the node_revision table, and before * field_attach_delete_revision() is called. * * @param $node * The node revision (node object) that is being deleted. * * @ingroup node_api_hooks */ function hook_node_revision_delete($node) { db_delete('mytable') ->condition('vid', $node->vid) ->execute(); } /** * Respond to creation of a new node. * * This hook is invoked from node_save() after the database query that will * insert the node into the node table is scheduled for execution, after the * type-specific hook_insert() is invoked, and after field_attach_insert() is * called. * * Note that when this hook is invoked, the changes have not yet been written to * the database, because a database transaction is still in progress. The * transaction is not finalized until the save operation is entirely completed * and node_save() goes out of scope. You should not rely on data in the * database at this time as it is not updated yet. You should also note that any * write/update database queries executed from this hook are also not committed * immediately. Check node_save() and db_transaction() for more info. * * @param $node * The node that is being created. * * @ingroup node_api_hooks */ function hook_node_insert($node) { db_insert('mytable') ->fields(array( 'nid' => $node->nid, 'extra' => $node->extra, )) ->execute(); } /** * Act on arbitrary nodes being loaded from the database. * * This hook should be used to add information that is not in the node or node * revisions table, not to replace information that is in these tables (which * could interfere with the entity cache). For performance reasons, information * for all available nodes should be loaded in a single query where possible. * * This hook is invoked during node loading, which is handled by entity_load(), * via classes NodeController and DrupalDefaultEntityController. After the node * information is read from the database or the entity cache, hook_load() is * invoked on the node's content type module, then field_attach_load_revision() * or field_attach_load() is called, then hook_entity_load() is invoked on all * implementing modules, and finally hook_node_load() is invoked on all * implementing modules. * * @param $nodes * An array of the nodes being loaded, keyed by nid. * @param $types * An array containing the node types present in $nodes. Allows for an early * return for modules that only support certain node types. However, if your * module defines a content type, you can use hook_load() to respond to * loading of just that content type. * * For a detailed usage example, see nodeapi_example.module. * * @ingroup node_api_hooks */ function hook_node_load($nodes, $types) { // Decide whether any of $types are relevant to our purposes. if (count(array_intersect($types_we_want_to_process, $types))) { // Gather our extra data for each of these nodes. $result = db_query('SELECT nid, foo FROM {mytable} WHERE nid IN(:nids)', array(':nids' => array_keys($nodes))); // Add our extra data to the node objects. foreach ($result as $record) { $nodes[$record->nid]->foo = $record->foo; } } } /** * Control access to a node. * * Modules may implement this hook if they want to have a say in whether or not * a given user has access to perform a given operation on a node. * * The administrative account (user ID #1) always passes any access check, so * this hook is not called in that case. Users with the "bypass node access" * permission may always view and edit content through the administrative * interface. * * Note that not all modules will want to influence access on all node types. If * your module does not want to actively grant or block access, return * NODE_ACCESS_IGNORE or simply return nothing. Blindly returning FALSE will * break other node access modules. * * Also note that this function isn't called for node listings (e.g., RSS feeds, * the default home page at path 'node', a recent content block, etc.) See * @link node_access Node access rights @endlink for a full explanation. * * @param $node * Either a node object or the machine name of the content type on which to * perform the access check. * @param $op * The operation to be performed. Possible values: * - "create" * - "delete" * - "update" * - "view" * @param $account * The user object to perform the access check operation on. * * @return * - NODE_ACCESS_ALLOW: if the operation is to be allowed. * - NODE_ACCESS_DENY: if the operation is to be denied. * - NODE_ACCESS_IGNORE: to not affect this operation at all. * * @ingroup node_access */ function hook_node_access($node, $op, $account) { $type = is_string($node) ? $node : $node->type; if (in_array($type, node_permissions_get_configured_types())) { if ($op == 'create' && user_access('create ' . $type . ' content', $account)) { return NODE_ACCESS_ALLOW; } if ($op == 'update') { if (user_access('edit any ' . $type . ' content', $account) || (user_access('edit own ' . $type . ' content', $account) && ($account->uid == $node->uid))) { return NODE_ACCESS_ALLOW; } } if ($op == 'delete') { if (user_access('delete any ' . $type . ' content', $account) || (user_access('delete own ' . $type . ' content', $account) && ($account->uid == $node->uid))) { return NODE_ACCESS_ALLOW; } } } // Returning nothing from this function would have the same effect. return NODE_ACCESS_IGNORE; } /** * Act on a node object about to be shown on the add/edit form. * * This hook is invoked from node_object_prepare() after the type-specific * hook_prepare() is invoked. * * @param $node * The node that is about to be shown on the add/edit form. * * @ingroup node_api_hooks */ function hook_node_prepare($node) { if (!isset($node->comment)) { $node->comment = variable_get("comment_$node->type", COMMENT_NODE_OPEN); } } /** * Act on a node being displayed as a search result. * * This hook is invoked from node_search_execute(), after node_load() and * node_view() have been called. * * @param $node * The node being displayed in a search result. * * @return array * Extra information to be displayed with search result. This information * should be presented as an associative array. It will be concatenated with * the post information (last updated, author) in the default search result * theming. * * @see template_preprocess_search_result() * @see search-result.tpl.php * * @ingroup node_api_hooks */ function hook_node_search_result($node) { $comments = db_query('SELECT comment_count FROM {node_comment_statistics} WHERE nid = :nid', array('nid' => $node->nid))->fetchField(); return array('comment' => format_plural($comments, '1 comment', '@count comments')); } /** * Act on a node being inserted or updated. * * This hook is invoked from node_save() before the node is saved to the * database. * * @param $node * The node that is being inserted or updated. * * @ingroup node_api_hooks */ function hook_node_presave($node) { if ($node->nid && $node->moderate) { // Reset votes when node is updated: $node->score = 0; $node->users = ''; $node->votes = 0; } } /** * Respond to updates to a node. * * This hook is invoked from node_save() after the database query that will * update node in the node table is scheduled for execution, after the * type-specific hook_update() is invoked, and after field_attach_update() is * called. * * Note that when this hook is invoked, the changes have not yet been written to * the database, because a database transaction is still in progress. The * transaction is not finalized until the save operation is entirely completed * and node_save() goes out of scope. You should not rely on data in the * database at this time as it is not updated yet. You should also note that any * write/update database queries executed from this hook are also not committed * immediately. Check node_save() and db_transaction() for more info. * * @param $node * The node that is being updated. * * @ingroup node_api_hooks */ function hook_node_update($node) { db_update('mytable') ->fields(array('extra' => $node->extra)) ->condition('nid', $node->nid) ->execute(); } /** * Act on a node being indexed for searching. * * This hook is invoked during search indexing, after node_load(), and after the * result of node_view() is added as $node->rendered to the node object. * * @param $node * The node being indexed. * * @return string * Additional node information to be indexed. * * @ingroup node_api_hooks */ function hook_node_update_index($node) { $text = ''; $comments = db_query('SELECT subject, comment, format FROM {comment} WHERE nid = :nid AND status = :status', array(':nid' => $node->nid, ':status' => COMMENT_PUBLISHED)); foreach ($comments as $comment) { $text .= '