The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
Currently displaying the same node with a different view_mode during field_attach_view (e.g. indirectly via entity reference), leads to avery strange error.
The reason is that node_build_content does:
$node->content += field_attach_view('node', $node, $view_mode, $langcode);
BUT
node_view does:
// Populate $node->content with a render() array.
node_build_content($node, $view_mode, $langcode);
$build = $node->content;
// We don't need duplicate rendering info in node->content.
unset($node->content);
Proposed resolution
+ // Operate the view on a clone of the node, to prevent someone changing it under us.
+ $node = clone $node;
+
// Populate $node->content with a render() array.
node_build_content($node, $view_mode, $langcode);
Remaining tasks
- Create Patch
- Check Drupal 8 for the same problem
- Create Tests
Comments
Comment #1
preshetin commentedIn this patch I implemented proposed resolution.
As for checking Drupal 8, I am not sure how to check it. I have searched for 'node_build_content' in Drupal 8 directory and did not find any matches.
It would be great to get some guidance on how to check it in Drupal 8, and how to create tests. Otherwise someone who is more experienced may try.
Comment #3
sivaji_ganesh_jojodae commented@Fabianx, some test cases are failing. You have any inputs for us?
Comment #4
fabianx commentedHm, it seems the RSS handling on core depends on this broken behavior.
#3 Can you try to run the RSS tests in isolation to see why and where they fail?
Thanks!
Comment #5
sivaji_ganesh_jojodae commented@Fabianx, thanks for mentoring. Sure, I tried as suggested. Find the inference below,
With respect to 'Comments as part of RSS feed.' test, when cloned version of $node is used the test fails because of missing comments tag in rss.xml page. See snapshot attached.
In fact taxonomy_term_view(), comment_view() and user_view() all seems to work the same way as node_view().
Comment #6
pradeepjha commentedComment #7
johnpitcairn commentedThe problem appears to be just trying to concatenate an array onto a null value?
A clone of the node would be passed to subsequent hook implementations that may make implicit assumptions about working with the same node object throughout the lifetime of the page.
Would it not be sufficient, in
node_build_content(), to test whether$node->contentis an array, and if not, create one, before attempting to concatenate thefield_attach_view()result?Comment #8
johnpitcairn commentedPatch against 7.x
Comment #9
johnpitcairn commentedComment #10
johnpitcairn commentedPasses, kills the strange operand error, and stays backwards-compatible for anything that checks
$node->content, can't see how this needs tests? And I would argue that other modules should be able to "change the node under us" via available hooks before it is rendered.Comment #11
johnpitcairn commentedThe build and field-attach implementation in Drupal 8 is radically different, but I don't think this problem persists there. Hopefully somebody else can back me up on that...
Comment #12
khaled.zaidan commentedI also went for sth similar to what's in #8. But the patch in #8 isn't enough (not in my case anyway)...
The problem is that $node->content gets unset after field_attach_view().
Solution: run field_attach_view() and store result in variable, and THEN ensure that $node->content is an array. (you also wanna check that it's not empty, to avoid an "undefined" warning...
Patch attached.
Comment #13
donquixote commentedComment #14
fabianx commentedClosing as duplicate of #564642: Preserve $node->content and $comment->content across multiple node views.