Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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?
Comment | File | Size | Author |
---|---|---|---|
#15 | entityreference-fix-target_id-1683964-15.patch | 886 bytes | odegard |
#3 | 1683964_entity_reference_empty_entity_ids-3.patch | 1.61 KB | hefox |
Comments
Comment #1
ryanrain CreditAttribution: ryanrain commentedi 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.
Comment #2
nickaloo CreditAttribution: nickaloo commentedI 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.
Comment #3
hefox CreditAttribution: hefox commentedtis calling entity_load on an array(0 => NULL) array, thus the array_flip errrors.
Comment #5
hefox CreditAttribution: hefox commentedtest failure makes no sense; undeinfed function??
Comment #6
drumm#3: 1683964_entity_reference_empty_entity_ids-3.patch queued for re-testing.
Comment #7
drummLooks good. This fixes one of the notices reported in #2073501: PHP notices when changing to non-existing project in 'create issue' form.
Comment #8
dman CreditAttribution: dman commentedThanks 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
Comment #9
Damien Tournoud CreditAttribution: Damien Tournoud commentedNeeds work:
(1) 0 is a valid entity ID (think: it's the anonymous user), so
empty()
is not right here, I supposeisset()
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.
Comment #10
dman CreditAttribution: dman commentedFWIW, 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.
Comment #11
Damien Tournoud CreditAttribution: Damien Tournoud commented@dman: so it's a problem in your migration path?
Comment #12
hefox CreditAttribution: hefox commentedI had it occur on a completely new install
Comment #13
WorldFallz CreditAttribution: WorldFallz commentedNot 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.
Comment #14
nesse0 CreditAttribution: nesse0 commentedI was getting the same error using the field group multiple module with entityreference fields with cardinality>1 and the autocomplete widget, and the patch from comment 3 resolved it for me. Many thanks!
Comment #15
odegard CreditAttribution: odegard commentedThere's no need to go as far as the patch in #3. A simple isset on target_id is enough, like #9 said.
This patch is also compatible with the patch for showing translated labels found here #1896210: When filtering autocomplete by a view #default_value always be the entity title instead of the custom view result (e.g. a field on the entity).
About #9 part 2, I'm not sure if there is a bug elsewhere. When you create a new node, there is no reference in place. One solution could be to always set a target_id but leave it empty, but doing an isset($item['target_id']) is what entityreference itself does in entityreference_field_is_empty(). So... I don't see any problems.
Comment #16
Kris77 CreditAttribution: Kris77 commented#15 work well for me.
Thanks
Comment #17
jwineichen CreditAttribution: jwineichen commented#15 worked for me on 7x-1.2
Comment #18
gaele CreditAttribution: gaele commentedComment #19
spotzero CreditAttribution: spotzero at Coldfront Labs Inc. commentedCommitted.