When deleting a field from a field_collection the following error occurs:

Notice: Undefined index: field_collection_item in field_info_instances() (line 685 of /customer/www/web119/web/modules/field/field.info.inc).

Comments

fago’s picture

Version: 7.x-1.0-beta1 » 7.x-1.x-dev
Status: Active » Closed (cannot reproduce)

I'm sry, I cannot reproduce this with the latest dev versions.

warbacon’s picture

This error appeared while creating a field collection with the latest dev.

Before saving the newly created field collection's field settings, the error would come up while viewing the new field collection's manage fields page. After saving the default settings for the new field, and settings for the content type it was being applied to, the error no longer appeared on the manage fields page.

Normally one would not do things in this order, but anyway... perhaps the individual above attempted to delete before saving as I did.

Anonymous’s picture

This also happens with Messages and with my module, SPARQL Views, which depend upon Entity API. It happens on the manage fields page the first time it is displayed, as comment #2 describes.

It has been posted in my queue at #1119516: Notice on managing fields of a SPARQL Views resource type

Anonymous’s picture

I believe that this is an issue with core. I have posted it here, #1121468: Notice when managing fields for entities with no fields attached

fago’s picture

Status: Closed (cannot reproduce) » Postponed

Thanks, given #2 I was able to reproduce it.

I've done some debugging and figured out this happens as the field-info cache is built without knowing the bundles when it is invoked from entity-info-alter. Thus, there is a wrong cache active then. To fix it clearing the field api cache once the bundle information is complete does it.

This does it fix for me:

diff --git a/field_collection.module b/field_collection.module
index 055ef0a..bea7b48 100644
--- a/field_collection.module
+++ b/field_collection.module
@@ -67,6 +67,7 @@ function field_collection_entity_info_alter(&$info) {
       );
     }
   }
+  _field_info_collate_fields(TRUE);
 }
 
 /**

However, I think we do better providing a generic function including this fix, so it works for all entity-API-consuming modules. See #1123236: Using hook_entity_info_alter to add bundles results in Notices on manage fields

fago’s picture

Status: Postponed » Fixed

The fix in the entity API should work for field-collection too. Be sure to updated to the latest entity API dev version and clear the cache to test it.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

elBradford’s picture

Status: Closed (fixed) » Active

I'm getting this message every time I run update.php. My exact error message is

Notice: Undefined index: field_collection_item in field_info_instances() (line 687 of /home7/marriot2/public_html/afrotc/modules/field/field.info.inc).

iGong’s picture

I too like elBradford. Unfortuanelly I didn't notice how the error started.

RyanPrice’s picture

I got this error immediately after install. All I did:

In drush:
drush dl field_collection
drush en field_collection

Then on the site, I went to the module list page and the error was there.

thersitz’s picture

I updated this module just now on 2 sites -- the error appears on 1 immediately after running update.php (on the Drupal database update landing page). The error did not show on the other site.

Notice: Undefined index: field_collection_item in field_info_instances() (line 687 of /home/content/t/h/e/xxxx/html/xx/modules/field/field.info.inc).

kosmonaut’s picture

I also have this error when Field Collection is enabled. I installed the latest version of the Entity and Field Collection modules (both modules had never existed on my install previously), and got the error right on the Modules page after I enabled Field Collection. If I disable it, the error goes away, and immediately comes back if I re-enable it. I am using the latest Drupal 7.12.

David Vespoli’s picture

Same issue. Entity updated to latest dev. Subscribing

gazik’s picture

FYI - I was having this issue at some point during development of a site (using pressflow 7), and out of frustration crtl-alt-del'ed the entire site to start over. I tried replacing the Entity API with the latest dev (would result in 'server cut the connection' error (running xampp). I started from scratch the n'th time and during the module enabling process- I kept running across the same error. I narrowed my woes to the calendar module (I put the latest dev (calendar 7.x-3.0+4-dev ). I disabled ONLY the calendar module, created a field for my home page, created a taxonomy vocabulary and added some terms, re-enabled the calendar module and haven't had the error reappear yet...
I am also using the latest dev of Date (date 7.x-2.2+8-dev)- not sure if that has anything to do with the error not re-appearing or not. Just thought I'd share.

tlangston’s picture

Thanks @Gazik - there is definitely some kind of compatibility issue with Calendar. All I did was disable Calendar and the errors cleared. I created a field collection, re-enabled Calendar and all is good. Crazy...

mattsmith3’s picture

I can confirm that disabling calender takes care of the error.

mikemadison’s picture

+1 can confirm the same as #16 and #17. Note that updating to the most recent version of calendar dev does NOT address this problem as of 3/24 (dev version is from 3/24 as well).

mikemadison’s picture

Status: Active » Needs review

Followed the link in #4 to http://drupal.org/node/1121468 which led to http://drupal.org/node/1245332 which has a patch http://drupal.org/files/field_info_instances_fix_returns-1245332-14-7.x_... to Core that I can confirm addresses this problem. I believe this issue can be resolved, as it is a problem with Core and not Field Collection.

Anonymous’s picture

Status: Needs review » Closed (duplicate)

It looks like this can be marked as duplicate if the core patch fixes it.

For anyone coming new to this issue, please test the patch that lalweil links to before reopening.

funature’s picture

the patch from #19 works for me