I'm sorry if this is duplicate, but I could not find any issues relating to this topic.

This is pretty straight forward. If I have a hook_node_view in my module, and then override the node view with a panel, then the node hooks are not invoked.

Comments

merlinofchaos’s picture

Status: Active » Closed (works as designed)

hook_node_view() is only invoked when node_view() is invoked. node_view() is only invoked if you include the Node: Content pane which actually views a node.

This isn't really a bug; I would like to find a good way to work around it, but it is not an easy fix.

If you really need this to happen, you can use something like hook_ctools_render_alter() to perform a node view.

pwaterz’s picture

Thanks Merlin,

Would it be worth changing this to a feature request?

Thanks,
Patrick

dariogcode’s picture

Some modules use node_view for perform other operations (for example fb_graph use this for setup meta tags in node page). Would be nice if this function can be invoked (at least for no lost other modules operations).

webdrips’s picture

hook_node_view() is called when node: content is added as a pane, but unfortunately it would seem it's being called too late (as adding a form to $node->content didn't work.

I really can't seem to find a good method to alter the node object.

hook_ctools_render_alter() won't work for me since the $info['content'] is HTML. If $info['content'] was similar to $node->content, I think I could make it work.

mcpuddin’s picture

Just one note, make sure that you uncheck "No Extras" or else hook_node_view will not fire.

roynilanjan’s picture

can be a workaround using hook_ctools_render_alter ,

function hook_ctools_render_alter(&$info, &$page, &$context) {
   $data = array_values($context['contexts']);
   // Below is nothing but to call hook_node_view which force to pass the
   // node object.
   module_invoke_all('node_view', $data[0]->data, 'full', '');

}

function [module-name]_node_view($node, $view_mode, $langcode) {
  // Here we can return a theme e.g.
  if ($node->type == 'article') {
    $node->content['somevar'] = $node->field_article_body;
    // Below will be a custom theme implementation using which we can render
    // any custom template & can implement corresponding preprocess 
    theme([theme-registry-name],array('somevar' => $node));
  }

}

andyg5000’s picture

Issue summary: View changes

When including node_content (add content > node > node content) in panels, be sure to uncheck "No extras
Check here to disable additions that modules might make to the node, such as file attachments and CCK fields; this should just display the basic teaser or body." if you want node_view functions to fire.

For example, I had a rule that displays a help message whenever a node is unpublished. This was not being executed until I unchecked the "No Extras" box.

ehsankhfr’s picture

Try to duplicate your php code for node_view inside the "PHP Code" inside the "Selection rules". However the logic for this part is based on returning False or True in the "PHP Code" inside the "Selection rules".

For me it worked fine!

ehsankhfr’s picture

using module_invoke_all() beside hook_ctools_render_alter is not a good idea in some situations!

Forcing the hooks in Drupal is not really recommended!

roynilanjan’s picture

@ehsankhfr: Eventually Drupal executes any hook using *module_invoke_all/module_invoke*(Which is basic architecture of drupal api calls).
Here in the above situation , if we enable *node_view* page of panel , means overriding the basic node view page & it's property and hence *hook_node_view* & any node pre-processor related hooks will not be triggered. So using the basic drupal api call mechanism we can enforce any function as *hook*.

as far #8 seems that we are trying to use PHP filter within panel variant selection rules, as internally PHP *eval* is reponsoble to parse it which is very costly interms of performance & we should try to avoid

ehsankhfr’s picture

Nice recommendation! However, in some situations, I believe using "PHP filter" can not be avoided, Such as: Contextual Filters in views for internal processing of some context for views.

roynilanjan’s picture

If we have an integration views and panel-page , & integration point is the contextual argument ... which can be easily integrated by *context API of ctools* & expose the token from that which will take care of the argument of view ... and for other any views component we can use the handlers (field,relation,filter etc)

roynilanjan’s picture

https://www.drupal.org/files/ctools-n1760384-13-d7.patch fix this problem, FYI that has been merged with current version ctools module.
Technical discussion have found in https://www.drupal.org/node/1760384