Hi, I'm really glad to have found this module besides using basic tables. I currently have an entity reference that I need to reference a user ID. However, when placing into the field groups table, I get this error:

Notice: Undefined index: target_id in entityreference_field_widget_form()(line 670 of /home/../modules/entityreference/entityreference.module).

Warning: array_flip() [function.array-flip]: Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load()(line 178 of /home/.../includes/entity.inc).

Any ideas?

Files: 
CommentFileSizeAuthor
#3 1683964_entity_reference_empty_entity_ids-3.patch1.61 KBhefox
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es).
[ View ]

Comments

ryanrain’s picture

Project:Field group multiple» Entity reference
Version:7.x-1.0-alpha11» 7.x-1.x-dev

i saw this error on an add content page (node/add/CONTENT_TYPE) with an entity reference field.

the error went away after i visited the admin page for the entity reference field that seemed to be causing the error, in my case: admin/structure/types/manage/CONTENT_TYPE/fields/ENTITY_REFERENCE_FIELD

the content type fields were defined by a features module. i had created the features module on another site where i ran a D6 upgrade that converted node reference fields to entity reference fields. i needed to migrate content type fields from one db to another in order to build the site on a fresh install of commons 3.

everything seems to be working as expected on my site, so i've assumed this to be resolved.

nickaloo’s picture

Version:7.x-1.x-dev» 7.x-1.0
Category:support» bug

I had the same problem within a multiple fieldgroup - I think it was to do with the cardinality; when I changed the widget type from autocomplete to select list the error went away, and I assumed it was because the number of entries needs to be "unlimited" to work the same as the other fields in the group.

hefox’s picture

Title:Entity Reference Error» Entity Reference Error (array_flip, undefined target_id) when using autocomplete and no entites selected
Status:Active» Needs review
StatusFileSize
new1.61 KB
PASSED: [[SimpleTest]]: [MySQL] 119 pass(es).
[ View ]

tis calling entity_load on an array(0 => NULL) array, thus the array_flip errrors.

Status:Needs review» Needs work

The last submitted patch, 1683964_entity_reference_empty_entity_ids-3.patch, failed testing.

hefox’s picture

Status:Needs work» Needs review

test failure makes no sense; undeinfed function??

drumm’s picture

drumm’s picture

Status:Needs review» Reviewed & tested by the community

Looks good. This fixes one of the notices reported in #2073501: PHP notices when changing to non-existing project in 'create issue' form.

dman’s picture

the error went away after i visited the admin page for the entity reference field that seemed to be causing the error, in my case: admin/structure/types/manage/CONTENT_TYPE/fields/ENTITY_REFERENCE_FIELD

Thanks for that, I had the same situation, and yes, that cleaned it up.

I can also confirm that this patch makes the error not appear - even from a fresh re-install that was triggering it for me.
+1 rtbc

Damien Tournoud’s picture

Status:Reviewed & tested by the community» Needs work

Needs work:

(1) 0 is a valid entity ID (think: it's the anonymous user), so empty() is not right here, I suppose isset() could be a valid choice
(2) This error message is just the sign of a bug elsewhere (because an entityreference target id cannot be validly NULL, see entityreference_field_is_empty())... if you hide the error under the carpet, you are never going to actually fix it bug.

dman’s picture

FWIW, the bug is replicable by using the D6-7 upgrade path.

* A D6 nodereference field is migrated to D7.
* Then the additional nodereference->entityreference conversion is done.
* At this point, the content *looks* stable, and existing content can be edited.
* But creating a new item, if no other admin refinement has happened, causes this fatal error.

In the normal course of events, we usually edit the content type field and display options before putting a D6-D7 converted site into use, so this issue dissolves. However, I've been running a fully-automated upgrade that feeds into user testing directly, and therefore this issue does re-occur for me.

I'm hoping that as our upgrade path is refined that a resave of the content type triggered from a 'features' update will smooth this out. But as is stands, this error at least can be replicated without too much work.

Damien Tournoud’s picture

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

@dman: so it's a problem in your migration path?

hefox’s picture

I had it occur on a completely new install

WorldFallz’s picture

Issue summary:View changes
Status:Postponed (maintainer needs more info)» Active

Not sure if this is related, but it seems possible. Though the patch in #3 doesn't fix it for me.

I'm using hook_widget_form_alter to add some extra validation to entityreference fields (via #element_validate) and I noticed this error while testing the autocomplete (non tagging) widget (cardinality makes no difference).

The short explanation is that the basic non-tagging 'autocomplete' widget $element variable looks different in hook_widget_form_alter than the other widgets (checkbox/radios, select list, autocomplete (tagging)).

So if you write code for an 'autocomplete' widget and someone changes it to one of the other widgets, you'll get the 'Notice: Undefined index: target_id in...' error.

This is the output of array_keys($element) from hook_widget_form_alter with checkbox/radio, select list, and autocomplete (tagging) widgets:

Array
(
[0] => #entity
[1] => #entity_type
[2] => #bundle
[3] => #field_name
[4] => #language
[5] => #field_parents
[6] => #columns
[7] => #title
[8] => #description
[9] => #required
[10] => #delta
[11] => #type
[12] => #default_value
[13] => #options
[14] => #value_key
[15] => #element_validate
[16] => #properties
)

With the plain (non-tag) autocomplete widget, array_keys($element) produces :

Array
(
[0] => target_id
)

However, if you then do array_keys($element['target_id']) you get the same (expected) keys as above:

Array
(
[0] => #entity_type
[1] => #entity
[2] => #bundle
[3] => #field_name
[4] => #language
[5] => #field_parents
[6] => #columns
[7] => #title
[8] => #description
[9] => #required
[10] => #delta
[11] => #weight
[12] => #type
[13] => #maxlength
[14] => #default_value
[15] => #autocomplete_path
[16] => #size
[17] => #element_validate
)

I even tried a 3rd party widget, entityreference_view_widget, and it shows the same array_keys($element) as the first group does.

It seems the autocomplete widget is somehow returning the wrong level of the tree. Now I can obviously test for $element['target_id'] and work around it, but I'm curious if this really a low level bug somewhere.