2

This is a followup to another question I asked abou creating your own hooks.

In the answer and comments, two functions were mentioned

module_invoke_all(...)
drupal_alter(...)

The function module_invoke_all appears to be used to invoke a hook for any module that implements it.

The function drupal_alter appears to invoke a hook for any module that implements it and passes around a persistant data structure between all the hook functions.

Digging through the code, I also found 

module_invoke(...)

which appears to let you invoke a specific hook in a specific module.

So, my question is really two questions. First, is my understanding of the above items correct. Second, are there any other core Drupal functions that can be used to invoke hooks implemented in a module?

My end goal is a better understanding of how the pieces of Drupal's architecture come together to form Drupal, the application, as most people use it. I'm starting with trying to understand the module system in isolation. Any corrections to glaring misconceptions are appreciated

Community
  • 1
  • 1
Alana Storm
  • 164,128
  • 91
  • 395
  • 599
  • 2
    One thing to note (that may help understand it) is that the hook system is nothing more than a procedural implementation of the OOP [Mediator Pattern](http://sourcemaking.com/design_patterns/mediator). So understanding that pattern *should* help you better understand the hook system... – ircmaxell Feb 14 '11 at 21:07
  • @ircmaxell I've got a decent handle (I think) on the hooks abstraction, it's where hooks/modules intersect with the rest of Drupal where things get fuzzy/confusing. – Alana Storm Feb 14 '11 at 21:11
  • Ahh, fair enough. I don't have much experience, so can't help you there, but figured the note on the mediator might help (I'll leave it in case future searchers come across it)... – ircmaxell Feb 14 '11 at 21:12
  • @ircmaxell no worries, the mediator point was appreciated – Alana Storm Feb 14 '11 at 22:01

1 Answers1

4

First question: Yes.

Second question: Apart from using these functions, you can also call module_implements() directly and call them manually. Example use case is when you want to pass arguments by reference but don't want an hook_something_alter() naming scheme that drupal_alter() forces you into.

module_implements() returns an array of modules that implemented the given hook. In Drupal 6 this is simply a loop over all modules and then checking if the function $module . '_' . $hook exists.

In Drupal 7, it is for example possible to define that your hook_yourmodule_something can be in a anothermodule.yourmodule.inc and Drupal will then automatically look for that file and include it when necessary. See hook_hook_info. Additionally, it is also possible to alter the list of modules that implement a hook, which is rather crazy and should be used with care. See hook_module_implements_alter.

Because these features make the discovery quite a bit slower than in D6, a cache was added to that. This basically means that whenever you add a hook implementation in D7, you need to clear the cache.

Example manual implementation:

<?php
// Custom hooks should always be prefixed with your module name to avoid naming conflicts.
$hook_name = 'yourmodule_something';
// Get a list of all modules implementing the hook.
foreach (module_implements($hook_name) as $module) {
  // Build the actual function name.
  $function = $module . '_' . $hook_name;
  // Call the function. Anything passed in to the function can be by-reference if the
  // hook_implementation defines it so. If you don't want that, you might want to give them
  // only a copy of the data to prevent abuse.
  $function($arg1, $arg2, $arg3, $arg4);
}
?>

If you look at the code of the functions you linked in your question, you can see that they are basically just helper function for the same procedure, so this should also help to improve the general understanding of hook calling.

Berdir
  • 6,881
  • 2
  • 26
  • 38
  • Thanks, that clarifies a lot. When I started investigating module hooks I assumed they were a non-class based implementation of an observer/listener, i.e. with some central authority responsible for calling each hook method the same way a listener implementation would check for registered callbacks when the system issued an event and called them. I've clearly proved the old saying about assuming! – Alana Storm Feb 14 '11 at 22:11
  • Well, they work similar in the end, the main difference is that they are "registered" based on naming conventions instead of explicitly register calls. That would simply be too slow as there are hundreds of possible hooks when you have many contrib modules installed but only a few are going to be called per page request. – Berdir Feb 14 '11 at 22:47
  • @Bendir: Right, but in most observer/listener patterns I've seen the system issues events, and listeners subscribe to do something. In Drupal hooks are invoked during the bootstrap process, and then certain modules themselves will invoke further hooks. That's the key different that's was tripping me up. I haven't seen many systems created based on events being issues, and then listeners for those events issuing further events. (Not saying it's bad, just that it's different from things I've seen before) – Alana Storm Feb 14 '11 at 23:12