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.
Comment | File | Size | Author |
---|---|---|---|
#18 | unset-_field_view_prepared-flag-before-field-view-1473228-1.patch | 737 bytes | joelpittet |
| |||
#1 | unset-_field_view_prepared-flag-before-field-view-1473228-1.patch | 737 bytes | klaasvw |
Comments
Comment #1
klaasvw CreditAttribution: klaasvw commentedThis 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.
Comment #2
tim.plunkettTriggering the testbot.
Comment #3
tim.plunkettCan you reproduce with entityreference module? References is on its way out, and I think that it might just be a bug on its end.
Comment #4
esmerel CreditAttribution: esmerel commentedper tim.plunkett's comments, I'm going to 'won't fix' this.
Comment #5
agileadamI 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.
Comment #6
agileadamI 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.
Comment #7
protonyx CreditAttribution: protonyx commentedI 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.
Comment #8
tim.plunkettComment #9
kenorb CreditAttribution: kenorb commentedCould be related: #1281114: Database records not deleted for Term Reference Fields after Term is Deleted
Comment #10
kenorb CreditAttribution: kenorb commentedHaving 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
Comment #11
webadpro CreditAttribution: webadpro commentedI'm facing the same issue.
Comment #12
webadpro CreditAttribution: webadpro commentedI'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.
Comment #13
jsacksick CreditAttribution: jsacksick commentedI 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.
Comment #14
marcoka CreditAttribution: marcoka commentedi 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
Comment #15
jkuma CreditAttribution: jkuma commentedAs 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!
Comment #16
colanWe'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.
Comment #17
colanComment #18
joelpittetre-uploading patch for testing from #1 that was previously RTBC
Comment #19
colanFrom #7:
Let's have someone look into this first. Or is it still an issue?
Comment #20
johan.gant CreditAttribution: johan.gant at Torchbox commentedI recently updated views to 7.x-3.14 and can confirm this patch is still required.
Comment #21
joelpittet@johan.gant, if it's still required patch and works then you can set the status to Reviewed and Tested by the Community
Comment #22
johan.gant CreditAttribution: johan.gant at Torchbox commented@joelpittet good point, now done!
Comment #23
Graber CreditAttribution: Graber as a volunteer commentedHmm, not included in 3.15 as well.
Comment #24
colanBefore we commit this, do we need to raise a separate issue for this in D8? Is it also a problem there?
Comment #25
Graber CreditAttribution: Graber as a volunteer commentedI'm applying the patch on 3.16 again, this issue is for 7.x-3.x branch, can we have the patch implemented in the next release?
Comment #26
joelpittetWhat would be good if we can update those steps to reproduce to work without DS and node reference if possible, then maybe it's something we can easily test in D8. Possible?
Comment #27
MustangGB CreditAttribution: MustangGB commentedRestoring status so this doesn't get lost.
Comment #28
DamienMcKennaMight anyone have some time to turn the testing instructions into an actual test, so we can make sure this bug doesn't come back again?
Thank you.