What is the basic concept behind hooks?
original source : http://drupal.stackexchange.com/questions/26290/what-is-the-basic-concept-behind-hooks
The other answers are great, accurate, detailed, but I’m not sure they’re the “simple words” explaining the bare bones of the concept that the asker was looking for.
I think of hooks as a point where the code pauses and shouts “Anyone else got anything to add here?”. Any module can have a function that replies to this, and gets triggered with appropriate data passed to it at that point in the code.
A nice straightforward example is hook_node_delete(). Any module can use it to make things happen every time a node is deleted. The docs tell you this hook passes the module the object of that deleted node to work with, and outlines other useful information such as about the exact timing of when it’s called (e.g. that it is before the node data is actually deleted from the database), and where in Drupal’s code the hook is called (which can be more than one place).
You can explore what hooks exist and find out what data is passed to them by exploring things starting with “hook_” in the Drupal api.
Hooks work by a name conventions: using hook_node_delete as our example, when the node deletion process reaches the point where the hook is called, for every module with a function like this [modulename]_node_delete() where the word hook in the hook’s name is replaced with the module’s name (e.g. my_amazing_module_node_delete() ), those functions get called.
Why? So any module can do anything at these key points: for example you could look at the deleted node and do things if it meets a certain condition (say, email an administrator, or launch some long process).
Some hooks let you alter things that have been generated just before they’re processed. For example, hook_menu_alter() passes you the current menu items that the system has generated. Any module can define a function some_modulename_menu_alter() and look at them, optionally change them (delete some, add some, sort them…), and pass the newly altered menu back in.
It’s simple, really powerful and is at the heart of how Drupal works as a modular system. Implementations of hooks are at the heart of most Drupal modules.
When looking through the code of a Drupal module, you can spot which functions come from hooks (as opposed to functions that are simply called from within the module code itself), as the Drupal community enforce a convention whereby each implementation of a hook has a comment in front of it like this (note the “Implements hook_…” bit):
/**
* Implements hook_some_hook().
*
* Some descriptive summary of what this does
*/
function my_amazing_module_some_hook() {Some modules that act as APIs define their own hooks. For example, Views defines many hooks that allow you to add to, read and edit data at various points in the process of creating or displaying a view. You can find information about hooks created in custom modules from two places (assuming the module follows conventions etc):
- The code and comments in the
modulename.api.phpfile in the module folder - drupalcontrib.org – for example, here’s their list of D7 modules they have info on, and here’s their page of Views hooks
Bootstrapping is, as others explained, basically booting up – I won’t duplicate the other good clear explanations.
One of the core developers wrote up an article a while ago called “Drupal programming from an object-oriented perspective”. It does a good job of explaining how hooks can be thought of as implementing many of the common design patterns. The best explanation of hooks comes from the article:
Drupal’s hook system is the basis for its interface abstraction. Hooks define the operations that can be performed on or by a module. If a module implements a hook, it enters into a contract to perform a particular task or return a particular type of information when the hook is invoked. The calling code need not know anything about the module or the way the hook is implemented in order to get useful work done by invoking the hook.
The Bootstrap is the process Drupal goes through to build a page, basically running over all the core, theme and module code in order.
It’s basically how Drupal boots up, and prepares to do it’s job as CMS.
It’s clever, in that it allows us to put hooks anywhere in our modules and themes, and the bootstrap process makes sure they get run at the right point.
For example if you use ‘hook_form_alter’ to add a custom check-box to a form, Drupal’s bootstrap will make sure it runs that code, just before it renders your form.
One issue with the bootstrap is that the entire process takes time to run, even if you are only returning a small amount of data. When using Drupal with the services module as an API and returning many small XHTML or JSON responses, running through the entire bootstrap isn’t very performant. Some clever people are looking at clever ways around this for Drupal 8.
But for rendering normal Drupal pages, the bootstrap process works great, it uses Drupals caching system to speed things up, and gives you total control over every part of your site. If you do find your site slow, you can always use something like APC or MemCached to help speed things up.
I hope my answer was accurate and explains things simply for you, I’m no expert, but I think that’s how it works.
Bootstrap is the process during the which Drupal initializes itself; the process actually includes:
- Setting the error, and the exception handlers
- Initializing the value of some spec-global variables contained in
$_SERVER - Initializing some variables with
init_set() - Finding the cached version of the page to serve
- Initializing the database
- Setting the handlers that load files when a class, or an interface is not found
- Initializing the Drupal variables
- Initializing the PHP session
- Initializing the language variable
- Loading the enabled modules
Some of the operations I described are specific for Drupal 7, or higher, but most of the operations are independent from the Drupal version.
A hook is a PHP function that can be called from Drupal, or third-party modules, when necessary to do a task. Instead of having a prefixed list of functions to call, the list is build checking the enabled modules, and the functions they implement.
For example, Drupal uses hook_node_update(); when a node is being saved with node_save(), the following code is executed.
// Call the node specific callback (if any). This can be
// node_invoke($node, 'insert') or
// node_invoke($node, 'update').
node_invoke($node, $op);What node_invoke() does is the following:
- Getting the list of all the enabled modules
- Checking if the enabled modules has a function whose name ends in “_node_update” and starts with the short name of the module
- Calling that function, passing
$nodeas parameter
Hooks can save their own data in a database, or alter the value returned from a function. The last case is, for example, what happens with hook_form_alter(), which alters the value of $form passed as reference to drupal_prepare_form().
Drupal hooks are generally invoked using three functions:
drupal_alter() is the function used to invoke specific hooks whose purpose is to alter the data passed them as reference, such as hook_form_alter(), hook_hook_info_alter(), andhook_tokens_alter().
There are other functions that are used to invoke hooks, such as node_invoke(), but those functions essentially use one of the functions I listed before.
What happened to media types?
