I have a view that accepts a node id as argument and displays several fields of that node, one of them being a node reference. When displaying this view on a node page I get the following errors:

Notice: Undefined index: node in node_reference_field_formatter_view() (rule 490 of references/node_reference/node_reference.module).
EntityMalformedException in entity_extract_ids()

The node page display is handled by display suite. As soon as I remove the node reference field from being displayed with display suite the error occurs.

After debugging I found out that the following issue occurs:

  • in views_handler_field_field field_view_field is called for all fields attached to the display
  • the $entity object passed to field_view_field is the same $entity object used for rendering the node on the node page (via the static entity load cache)
  • this $entity object already has the $entity->_field_view_prepared flag set to TRUE (node_view was already called). This means it won't call hook_field_formatter_prepare_view anymore when displaying fields of that particular entity
  • any hook_field_formatter_view that is called (through field_view_field) has to rely on the data attached to the $entity object that was originally used for rendering the node for the node page.
  • if the field is not displayed on the node page (by removing it from the view mode) and relies on data set in hook_field_formatter_prepare_view (like node references) an error will occur

You can replicate it using these steps:

  • create a content type with a node reference field
  • create a view accepting a node id as argument, using fields for display and showing the node reference field
  • using display suite, add the view as a dynamic field to the node for its full view mode
  • remove the node reference field from display for the full view mode
  • create a node of this type with a populated node reference field
  • go to the node page

This should result in a similar bug as above.

Patch follows.


klaasvw’s picture

Status: Active » Needs review
737 bytes
PASSED: [[SimpleTest]]: [MySQL] 1,658 pass(es). View

This patch will reset the _field_view_prepared flag on the entity object before field_view_field is called. Without this flag hook_field_formatter_prepare_view will be called on the field.

I'm aware that can be argued that this bug needs to be solved in another place. It could be fixed in node_reference.module of references but I believe the API is being used correctly (prepare for attaching data needed for display). Display suite might be another candidate but I can't see how display suite can know which fields views is about display and how it can account for fields being displayed in views that were not loaded for the node on the current page.

tim.plunkett’s picture

Triggering the testbot.

tim.plunkett’s picture

Status: Needs review » Postponed (maintainer needs more info)

Can you reproduce with entityreference module? References is on its way out, and I think that it might just be a bug on its end.

esmerel’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

per tim.plunkett's comments, I'm going to 'won't fix' this.

agileadam’s picture

I believe I am experience this issue with Entity Reference. I'll post again when I know more, but right now I am certain that entityreference_field_formatter_prepare_view() isn't being called when showing a block as a Display Suite field. The Views block has a NID argument (successfully populating), and the single entity reference field is shown as "Rendered Entity."
If I render the block as a normal block, everything works find. If I put the block into Display Suite, it gives me this error:

Fatal error: __clone method called on non-object in [module_path_here]/entityreference.module on line 1012.

Within entityreference.module, around line 1012.
WORKS: $entity = clone entity_load_single($entity_type, $item['target_id']);
BROKEN: $entity = clone $item['entity'];

So, after realizing the entities weren't loaded, I checked if entityreference_field_formatter_prepare_view() is executing, and it's not. That's where the entities were being loaded into $items.

Sorry this isn't a very put-together reply... but I wanted to get something out there to confirm I do believe there's an issue.

agileadam’s picture

Status: Closed (won't fix) » Active

I just added the "unset($entity->_field_view_prepared);" line to modules/contrib/views/modules/field/views_handler_field_field.inc and found that the issue is resolved (without modification to entityreference or display suite).

Do you need more details? I know my last writeup was awfully sloppy.

protonyx’s picture

Version: 7.x-3.x-dev » 7.x-3.5

I am experiencing this same issue with a similar setup as the original description. When I try to use a view from within display suite as a dynamic field the same error is thrown. There are also errors about a taxonomy reference I have as one of the fields in the content type.

Update: I am experiencing this issue with the latest dev build of entityreference

Update: adding unset($entity->_field_view_prepared); into views_handler_field_field.inc works fine, but I wonder if there is a better solution to this issue. Correct me if I am wrong, but wouldn't this cause some extra overhead to prepare fields that may have already been prepared? I am curious if this is going to cause a performance issue.

tim.plunkett’s picture

kenorb’s picture

kenorb’s picture

Status: Active » Needs work

Having similar error, but patch didn't help much.
Also tested taxonomy_orphanage module and it didn't detect any orphaned taxonomy references.
Backtrace: http://drupal.org/node/1778572#comment-7256200

Could be related to Search API:
#1402270: ResponseText: EntityMalformedException: Missing bundle property on entity of type profile2

webadpro’s picture

I'm facing the same issue.

webadpro’s picture

I'm facing the same issue and patch #1 has fixed it for me also.

Here's a way to test it out.

Have a taxonomy page that is using Taxonomy display.

On that taxonomy term add a Term reference field and reference to another term.

Then create a view for the term that would output the term reference field.

You'll run into the issue.

jsacksick’s picture

Status: Needs work » Reviewed & tested by the community

I can confirm the bug with Entity reference, the hook_field_formatter_prepare_view() never gets called, as a consequence the access flag added by this function is not added, and the hook_field_formatter_view() doesn't return anything because of this.
The patch makes it work.

marcoka’s picture

i had that patch too when using https://www.drupal.org/project/embed_views to embed a view into a node.

the view itself worked perfectly, just when i mebedded it i got the error

EntityMalformedException: .. taxonomy_term. in entity_extract_ids() (Zeile 7734 von /mnt/www/WORKSPACE_DRUPAL/EIGENE_PROJEKTE/PRODUCT_DISTRI3/includes/common.inc).

#2268293: EntityMalformedException

jkuma’s picture

As jsacksick said, this patch resolves a critical issue with entityreference module. The _field_view_prepared flag attached on passed entity prevents views to invoke entityreference own preparation callbacks and since the items to be rendered are not prepared, entityreference unsets them hence nothing is displayed.

This patch solves this issue for me!

colan’s picture

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

colan’s picture

Status: Reviewed & tested by the community » Needs work
joelpittet’s picture

Status: Needs work » Reviewed & tested by the community
737 bytes

re-uploading patch for testing from #1 that was previously RTBC

colan’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

From #7:

Update: adding unset($entity->_field_view_prepared); into views_handler_field_field.inc works fine, but I wonder if there is a better solution to this issue. Correct me if I am wrong, but wouldn't this cause some extra overhead to prepare fields that may have already been prepared? I am curious if this is going to cause a performance issue.

Let's have someone look into this first. Or is it still an issue?

johan.gant’s picture

I recently updated views to 7.x-3.14 and can confirm this patch is still required.

joelpittet’s picture

Status: Postponed (maintainer needs more info) » Needs review

@johan.gant, if it's still required patch and works then you can set the status to Reviewed and Tested by the Community

johan.gant’s picture

Status: Needs review » Reviewed & tested by the community

@joelpittet good point, now done!