7

In an old blog post, Larry Garfield refers to "registry-style" hooks and hook_nodeapi type hooks.

When it comes to breaking down the different types of hooks, there doesn't seem to be any documentation. There is the big list of hooks and Tim Plunkett found two defgroups dealing with hooks, but there doesn't seem to be a formal breakdown of what different types of hooks we have.

What would such a breakdown look like?

  • Interesting question. Are you after a theoretical discussion or is there a specific problem you're trying to solve? – marcvangend May 29 '11 at 20:06
  • 2
    I'm asking for a few reasons. 1) helps with writing my thesis 2) would be good for the documentation because the different types of hooks confuse newbs 3) Would be good to know when designing modules and for core development, helps isolate best practices and where best practices aren't in place – linclark May 29 '11 at 20:23
7

I would group them in three, four groups, but there is no technical/internal difference between them. All are just functions that are called because of naming conventions.

  1. Info hooks. Hooks that provide information about something, typical examples are hook_entity_info(), hook_field_info(), hook_hook_info() but also hook_permission(), hook_menu(), hook_theme(), etc. Many of these have a _info suffix but don't necessarly need to. These hooks can be called any time and the returned information is often cached (static cache or persistent cache) or stored to specific tables (e.g. hook_menu()).

  2. Reactive/Action hooks. I just invented that name, but these are hooks which are called when something specific happenend like hook_init(), hook_node_save(), hook_user_save(), hook_node_view() and so on.

  3. Alter hooks. Hooks that can be used to change something provided by other modules, exist for almost any info hooks (e.g. hook_menu_alter() or hook_entity_info_alter()) and also some action hooks (e.g. hook_node_view_alter()).

There is also a forth group but those are actually not really hooks and they are one of the main reasons for the typical confusion about hooks. They are often referred to as "Callbacks". This are "Hooks" which are only called for a single module, which owns something. Typical examples include node type callbacks (hook_submit, hook_view, hook_form, ...), many field hooks (e.g. hook_field_load()) but also hook_block_view(). There are plans to remove these and replace with something else (oop based) or rename them to something else than hooks.

I assume there are also some hooks that can't be correctly put in any of these groups or are a mix of those groups. If so, that might be a sign that they should be redesigned. If someone knows any examples, I can add it here.

Disclaimer: This is not official but how I see it. Use with caution. ;)

0

Reading Larry's blog post, I don't think he meant to say that there are only two kinds of hooks (registry-style and nodeapi-style). As far as I know, there are no official types of hooks defined. Basically, all hooks are technically similar, but there is a difference in what they to and when they do it.

Hooks can be invoked anywhere between the initial http request and returning the output. Most hooks are meant to influence that (usually html) output one way or the other (call them 'normal hooks' if you like), like hook_init for example.

Some hooks are not meant to affect the output directly, but they add to or alter a registry that is being stored in the database. This is what Larry calls registry-style hooks. They are not invoked often, but build a persistent list of values that can be used over and over again. Storing it in the database as a registry improves performance. This is what hook_menu and hook_theme do, among others.

The 'nodeapi-style' that is mentioned in the blog refers to hooks that bundle a bunch of subroutines in a single hook implementation. In D6, an implementation of hook_nodeapi can respond to multiple events, like saving a node, viewing a node and deleting a node. This type of hook no longer exists in D7; for instance the single hook_nodeapi has been replaced by hook_node_insert, hook_node_view, hook_node_delete and a bunch of similar hooks.

  • I didn't mean to suggest that there are only two kinds of hooks. I'm looking for a categorization of what different hooks do. For example, there are some callback hooks (that probably shouldn't be hooks at all, as Berdir points out with his fourth group above) that only operate on the node type defined within the module. – linclark May 29 '11 at 21:42
  • OK, I wasn't sure if you meant to suggest that. Anyway, I think my answer is in line with Berdir's 3+1 categories, I support his answer. – marcvangend May 30 '11 at 7:19
0

One way to split them up is in terms of input and output: 1) input-only, 2) output-only, 3) input-output, and 4) no input, no output.

There's not a lot of #1, since nearly anything that happens could have some sort of response. The only examples I can think of are delete hooks, e.g. hook_file_delete(), hook_comment_delete(), where the hook gets the deleted object, but that object is already deleted, so there's no reason for a response.

The "registry-style" hooks would be #2, output only. They just feed data into a central registry and don't take any input. hook_menu() and hook_help() are examples.

hook_nodeapi() was #3, but now it's broken up into different functions like hook_node_presave() -- still #3 -- and hook_node_delete() -- which is now #1. This is the most common group. Many of the examples explicitly have the word "alter" in the hook name, e.g. hook_form_alter().

Something like hook_init() would be #4. Beyond general notification of an event, there's no input nor output.

That's a pretty arbitrary break-down though. You could easily argue for breaking up #3 into hooks where the output has the same structure as the input (alter) vs. hooks where the output has a completely different structure (call-response). Or you could combine #1 and #4, since the function call itself is a type of input, so the difference is just in level of detail.

  • hook_menu_alter is also registry only, but it "takes input". – tim.plunkett May 29 '11 at 20:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.