1

Let's say, for instance, that I want to quickly view the variables sent to HOOK_preprocess_node(), but I'm too lazy (if I'm just being honest) to edit my template.php file just to do that one check.

Can devel's Execute PHP block allow me to do something like this?

function SOMETHING_preprocess_node(&$vars) {
  dpm($vars);
}

Or is it impossible to use hooks in this context?

To clarify, my somewhat lofty goal is to be able to experiment with virtually any hook function quickly using Devel's PHP execution, and if there's a syntax for doing that. I realize there are some problems with that concept from the get-go, not the least of which is that you need to artificially create a context in which certain hooks will even be called, but I want to see what's available.

EDIT: Tenken's answer got me thinking. I could create a global array called, say, $devel_hooks. In a module, I could populate this variable with the contents of various hooks like so:

$devel_hooks = array();

function devhooks_preprocess_page(&vars) {
  global $devel_hooks;
  $devel_hooks['preprocess_page'] = $vars;
}

The contents of $devel_hooks could then conceivably be accessed at will, BUT there's a problem: Devel's Execute PHP block evaluates its content immediately on form submit and before the page loads again, so I couldn't put, say, dpm($devel_hooks['preprocess_page']); in there and get anything out of it because the page and its hooks haven't been processed yet, so $devel_hooks is completely empty or may even be undefined when that PHP is evaluated.

So maybe I could populate another global array with the information I want to request from $devel_hooks, and have the latest possible page hook (which might be HOOK_page_alter()?) parse that array and run a dpm() on the requested components of $devel_hooks. You would then, obviously, need to execute the PHP on a page that would use the desired hooks, but that's on you. I just haven't quite figured out how to connect those dots.

I could, conceivably, populate the array with strings and map those to array keys, but what if I want to dpm() something deeply nested in one of the hook arrays, like $devel_hooks['preprocess_node]['elements']['body']['#markup'] (just as an example, may not be accurate to what that array would look like)?

2 Answers 2

4

The main problem with simulating any hook is that the hook only makes sense in the context of whatever is doing the invoking.

Hooks get fired either from a module_invoke() or a module_invoke_all(). These functions assume that the hooks have already been found and exist in the registry. They also take into account the invocation order (by weight, then alphabetically by module name).

The process and preprocess hooks are little different as the hook parameters get passed in by reference, and there is a more complex calling scheme, so the order really does matter for what is present in $variables.

The net result is that you can't really fake out a hook without actually implementing the hook somewhere.

Personally, I keep a devel module around with the most common hooks stubbed out as empty functions. I also stub out common process/preproess and form alters. This way I can dpm() something whenever I want without needing to do a cache clear. For example, I have a high-weigh module with

/**
  * Implements hook_form_alter().
  */

function mytestmodule_form_alter(&$form, &$form_state, $form_id) {
  // dpm($form_id, 'form_id');
  // dpm($form, 'form');
  // dpm($form_state, 'form_state');
}

in it. This way, Drupal already knows about the hook in the registry. All I need to do is uncomment / edit the function as needed.

4
  • You have a bunch of stubbed out what ? That help to you dpm() what exactly? You run dpm(mydevelmodule_user_login($account)) ? Can you please expand on this ...
    – tenken
    Aug 8, 2013 at 21:03
  • @tenken Drupal caches the existence of hooks but not their content, so if you add a hook to an already installed/enabled module you need to clear your cache before Drupal will attempt to find it. If the function already exists it can be edited at will. So he has a custom module with a bunch of empty hooks. If we wants to output Devel information (or whatever) he just edits the module file and he doesn't have to do a cache clear to see the results. It's not quite what I asked for, but it may be the most convenient way possible to examine hook variables.
    – Eric N
    Aug 9, 2013 at 14:56
  • +1 for the tip on keeping the stubs so you eliminate the need to do cache clears. I've always just randomly chosen a module and added the hook in it when I needed to debug, this (your way) is much cleaner. Aug 9, 2013 at 15:13
  • I get it now. Yea this is pretty clean -- i might start doing this as a development best-practice.
    – tenken
    Aug 9, 2013 at 19:40
1

You can use either the devel tab on the content, or devel_themer to see all of this.

1
  • While I'm glad you opened me up to actually paying attention to that Devel tab, it looks like it allows me quick access to the node object and the output of node_view(), but not some of the other processing functions. Besides, what I'm really interested in is the capability to arbitrarily implement any API hook, not necessarily just theme hooks.
    – Eric N
    Aug 8, 2013 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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