Cruft in $page due to node_build, comment_build, etc.

Just filed a related issue #564642: Preserve $node->content and $comment->content across multiple node views. I do not believe they are the same but relatively close.

Removing this looks fine by me, but then we should also remove the equivalents in comment_build(), user_view() (heh, who's inconsistently named ? surprise...)

That's awesome!

Looks like sensible clean-up. I like that the comment/user/node build functions are all harmonized now.

I had questions about the changes to user_page_title(), but it appears that we're overriding those in user_view() anyway, since on d.o, the title of http://drupal.org/user/24967 is not "My account" but "webchick". So this appears to be old cruft that doesn't apply anymore.

I asked Moshe to give the hook_page_alter() docs a spot-check and he said there was nothing that needed updating.

Committed to HEAD.

Nearly 3 years on, a small issue has arisen from this patch.

Steps to replicate are difficult, it requires a recursive rendering of the same entity. I discovered this when using an insert view filter that rendered the node that contained the filter was being rendered.

In a nut-shell:

Render a node.
Embed the same node somewhere within the build process.
This internal rebuilding results in "unset($node->content);"
Since it is an object, this also unsets the parent node's content array.
So at the end of field_attach_view() in the main node, you get "Fatal error: Unsupported operand types in modules/node/node.module on line 1362"

While normally I would just consider this as a idiots mistake, recursive looping is becoming more common.

IE: Another hypothetical examples:
Product has sub-products entity references and displays these. The sub-products hook into the field system decide to render the reverse relationship.

My first thoughts are that we shouldn't unset this and that we should reuse the content as required (memory overhead may be high). However, different view modes means that this is unsafe. So a bigger refactoring would be required to store the content along with the view mode.

Something like this ever so simplified pseudocode:

function render_entity_content ($entity, $view_mode) {
  if (isset($entity->content[$view_mode])) {
    return $entity->content[$view_mode];
  }
  else {
    $entity->content[$view_mode] = real_render_entity_content($entity, $view_mode);
  }
}

Back to the actual error, one work-around is:

  // Store any existing content in case of recursive calls to node_view().
  $existing_content = isset($node->content) ? $node->content : NULL;

  // Populate $node->content with a render() array.
  node_build_content($node, $view_mode, $langcode);

  $build = $node->content;
  // Restore any existing content.
  $node->content = isset($existing_content) ? $existing_content : NULL;

And similar solution for user_build()

This reworks the workaround in #11 slightly.

Moved to #564642: Preserve $node->content and $comment->content across multiple node views