When a view is attached to a node with Eva, and that view references the same node to which it is attached (i.e. you're viewing a node page, and there's a view attached to that page that includes the node in its data set), the node template receives a value of FALSE for the $page argument.

The offending code appears to be on line 255 of views.module, in views_preprocess_node():

      // If a node is being rendered in a view, and the view does not have a path,
      // prevent drupal from accidentally setting the $page variable:
      if ($vars['page'] && $vars['view_mode'] == 'full' && !$vars['view']->display_handler->has_path()) {
        $vars['page'] = FALSE;
      }

It looks like the views pre-process function makes an incorrect assumption about when it is safe to bash to $page variable.

Not sure what the best way to proceed is from here...

Comments

dawehner’s picture

Well it's better to set the page variable more often then needed,
because with it active a lot of strange things happens if you don't expect that.

I guess the main issue here is that both $node are pointing to the same space in memory, so maybe views should do a clone of $node before doing something.

dawehner’s picture

Issue summary: View changes

Typo.

rooby’s picture

Title: Rendering views on nodes with Eva can cause $page in node.tpl.php to be FALSE when it should be TRUE » Rendering node views on node page can cause $page in node.tpl.php to be FALSE when it should be TRUE
Version: 7.x-3.3 » 7.x-3.x-dev
Issue summary: View changes

This is not specific to EVA so changing title.

This is an odd bug. I've looked into it a bit but have no solution yet.

There is a problem whenever you have a node page that also has a view somewhere on it that is outputting that same node again.

For some reason when the 2 instances of the node get rendered they both have the view object on them so when views_preprocess_node() does

<?php
  if (!empty($vars['node']->view) && !empty($vars['node']->view->name)) {
?>

it passes also for the main node of the page and runs

<?php
      // If a node is being rendered in a view, and the view does not have a path,
      // prevent drupal from accidentally setting the $page variable:
      if ($vars['page'] && $vars['view_mode'] == 'full' && !$vars['view']->display_handler->has_path()) {
        $vars['page'] = FALSE;
      }
?>

I'm not sure yet though why the main node of the page has $node->view on it.

Form a quick look it seems views_plugin_row_node_view::render() is where the view gets added to the node and that shouldn't be affecting the main node.

I have disabled the entitycache module and other drupal caching and still the problem persists...

Thinking just now. node_load_multiple() gets some caching affect from the entity controller right? possibly could that be related to what is happening?

rooby’s picture

Status: Active » Needs review
StatusFileSize
new539 bytes

Following on from that idea, this patch fixes the problem.

I'm not entirely sure whether this is the correct fix however it illustrates the problem.

chris matthews’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

The 4 year old patch in #3 to views_plugin_row_node_view.inc does not apply to the latest views 7.x-3.x-dev and if still relevant needs to be rerolled.

Checking patch modules/node/views_plugin_row_node_view.inc...
error: while searching for:
    foreach ($values as $row) {
      $nids[] = $row->{$this->field_alias};
    }
    $this->nodes = node_load_multiple($nids);
  }

  function render($row) {

error: patch failed: modules/node/views_plugin_row_node_view.inc:95
error: modules/node/views_plugin_row_node_view.inc: patch does not apply
rooby’s picture

I'll re-reoll this one ASAP

rooby’s picture

Status: Needs work » Needs review

When I try against latest 7.x-3.x git branch it applies properly (although with fuzz).

patch -p1 < views-node_load_caching-1574806-3.patch
patching file modules/node/views_plugin_row_node_view.inc
Hunk #1 succeeded at 120 with fuzz 1 (offset 25 lines).

How were you applying that patch when it failed?

rooby’s picture

StatusFileSize
new523 bytes

Ah I see. git apply doesn't work if there's fuzz.

Here's one with no fuzz.

andrew answer’s picture

Issue tags: -Needs reroll