hook

Hooks are used in Drupal to allow modules and themes to listen to or trigger different sorts of events in a Drupal system. During these events Drupal will pause and ask if any modules want to have any say in the event that is currently being triggered.

For example, hooks are commonly used when content is viewed, created, updated, or deleted. So, if we delete a page of content then a delete hook is triggered which allows modules to react to that content item being deleted. Using this, we can react to this and perform clean up operations on items of content that don't exist any more. Our custom module might want to remove items from a database table, or delete associated files since they wont be needed.

This is just one example of how hooks are used in Drupal as they are used in all manner of different situations, and not just listening for content events. Another example of a common Drupal hook is when creating a custom template.

I have written lots of detail about using update hooks to manage updates in Drupal and they have all been about the hook_update_N() hook. The hook_update_N() hook is just one of the options available in running updates as the update pipeline also includes hook_post_update_NAME(). The hook_deploy_NAME() hook, bundled with Drush 10, can also be used as an update hook in the same way.

Each of these update hooks has a number of different best practices when considering their use. All of these hooks are run once and once only and the key idea is that they take Drupal (or a module) from one version to another by adding database changes or configuration updates as the module gets updated.

For example, if you have a module that has a database table then it will be stored as schema information within your module. Once you release the module you must ensure that everyone who already has the module installed can still use it after the schema has changed. This means that as well as updating the schema information you also need to provide steps in the update hooks to update existing installs. Without this step the module would likely crash as it attempts to inject data into tables or fields that don't exist.

Or, how you can render a Drupal page with an entirely different template.

I recently had a requirement where I needed to get Drupal to render a single page of HTML that was entirely separate from the normal page layout of a site. This was actually part of an API callback, but this got me involved in looking at how delivery callbacks work in Drupal 7. It isn't necessary to create a new theme just for the job of rendering a single page with some custom HTML, especially as Drupal has mechanisms to provide this built in.

Organic Groups (OG) in Drupal 7 has a role based permission system that works on a group by group basis. This permissions system works separately to the main Drupal permission system, which can cause a couple of issues. For example, if you want to give a group role access to give other users roles then you'll need to give them the 'Administer groups' permission. The downside of this is that it overrides Drupal's core permissions to do with node deletion and allows the role to delete the group. Allowing any user to delete groups can lead to all sorts of problems so an alternative is needed.

The group people admin page (found at group/node/%nid%/admin/people) has a bulk operations form that allows users with access to the form to manage user group membership. To allow or deny a member a user just needs to select them from the list, select the action required and click Update. Here is the select statement from that page.