The problem

When enabling Features modules that contain field collections on a site for the first time, errors such as the one in the original summary below can be encountered. This seems to be due to how Entity API handles exports: #1864840: Change exports to be nested arrays rather than entity_import'd JSON objects provides another example of a similar export approach.

This causes a function call (entity_import()) to occur in featurename_default_fields(), and this fails if the fields haven't been created yet. They won't have been created yet if it's the first time turning on the feature.

Only happens if

This only happens if there are default values set from within the content type's Field Collection field. It is fine and recommended to set default values on the individual fields through Structure -> Field collections -> [field collection] -> [field collection item field] -> edit.

Steps to reproduce

These are not tested on a clean install, but they should reproduce the issue:

  1. Create a Field Collection field on a content type.
  2. Create some fields - text fields, text areas, or ones where you can set a default value easily. Select lists caused it in my case, actually. One should be enough.
  3. Go back and edit the Field Collection field on the content type. Enter in a default value.
  4. Install Features 7.x-1.0 if not present.
  5. Export the Field Collection and its fields in a feature. Save it and put it in sites/all/modules.DON'T ENABLE IT YET.
  6. Go back to the content type and delete the Field Collection field.
  7. Enable your Features module now.

Expected behavior

Field Collection field and child field(s) get created again.

Actual behavior

Features screen errors out. Closer examination reveals the error condition in the comments.

Comments of particular note: #13, #19, #20.

Workaround

See #22.

Suggested resolution

See #23.

Original title: Unknown field: field_foo in EntityFieldQuery->addFieldCondition() / other errors when deleted field collection fields are purged
Original summary:

Hello there,

I created a Field Collection field with a couple of fields inside then, deciding it wasn't correct deleted the Field Collection field without removing the fields inside it first (not sure whether this would cause the problem or not) and now receive the following error when I delete a field from a content type:

EntityFieldQueryException: Unknown field: field_foo in EntityFieldQuery->addFieldCondition() (line 767 of /var/www/calendar/includes/entity.inc).

The field gets deleted in the content type, but because of this error I have to return to the content field page manually (url) and it ruins the work flow... And I have a lot of fields to get through :S

Any one have any ideas? I can remove the module, run cron etc to get rid of the errors but I'd quite like to use the module!

Cheers
Dan

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fietserwin’s picture

The stack trace I get when trying to delete a field collection from a content type:

`
http://localhost/ (suspended)	
	fieldCondition(): /includes/entity.inc at line 767	
	fieldCondition(): /includes/entity.inc at line 660	
	field_collection_field_delete(): /sites/all/modules/field_collection/field_collection.module at line 650	
	_field_invoke(): /modules/field/field.attach.inc at line 209	
	field_purge_data(): /modules/field/field.crud.inc at line 910	
	field_purge_batch(): /modules/field/field.crud.inc at line 870	
	field_ui_field_delete_form_submit(): /modules/field_ui/field_ui.admin.inc at line 1790	
	form_execute_handlers(): /includes/form.inc at line 1443	
	drupal_process_form(): /includes/form.inc at line 854	
	drupal_build_form(): /includes/form.inc at line 374	
	drupal_get_form(): /includes/form.inc at line 131	
	menu_execute_active_handler(): /includes/menu.inc at line 516	
	/index.php at line 21	

And more or less the same stack trace when I subsequently run cron:

http://localhost/ (suspended)	
	fieldCondition(): /includes/entity.inc at line 767	
	fieldCondition(): /includes/entity.inc at line 660	
	field_collection_field_delete(): /sites/all/modules/field_collection/field_collection.module at line 650	
	_field_invoke(): /modules/field/field.attach.inc at line 209	
	field_purge_data(): /modules/field/field.crud.inc at line 910	
	field_purge_batch(): /modules/field/field.crud.inc at line 870	
	field_cron(): /modules/field/field.module at line 342	
	module_invoke(): /includes/module.inc at line 799	
	drupal_cron_run(): /includes/common.inc at line 5145	
	system_run_cron(): /modules/system/system.admin.inc at line 2330	
	menu_execute_active_handler(): /includes/menu.inc at line 516	
	/index.php at line 21	

The field that gets listed in the error message is part of the field collection I tried to delete but has apparently already been removed (or tagged for deletion) when your hook_field_delete is called.

This is pretty irritating as cron cannot run to completion, and thus your module cannot be disabled as it is "Required by: Drupal (Fields pending deletion)" on the module listing page.

dynamicdan’s picture

I just got the same error. I had cautiously deleted the fields in the field collection first with no problems. Only when removing the field collection field itself did I have problems (as above).

The table/field has however been removed and I don't seem have to any CMS/field issues.

michaelfavia’s picture

Confirmed issue as well. I havent debugged it yet but wanted to voice +1 and subscribe. Will post results as i fix it.

sudev.pradhan’s picture

If the field collection module is disabled and enabled again then the issue should be resolved. (It did the trick for me!)

If you cannot disable the module because of "required by Drupal, fields pending deletion" issue (even when there are no fields "pending deletion") then - delete the module folder, run cron, then replace the module directory.

Also, check this issue queue - http://drupal.org/node/1400478#comment-5602338

richshaw101’s picture

I've had this problem as well. I think it's something todo with deleted fields flagged as deleted field_config & field_config_instance tables not being removed. See: http://drupal.org/node/1340390.

I ended up manually calling field_purge_field($field) & field_purge_instance($instance) on the offending items, which seems to have fixed the problem for the time being/not a proper fix.

osopolar’s picture

I linked the "post installation" support request (EntityFieldQueryException: Unknown field:) to this ticket.

brettbirschbach’s picture

Thanks richshaw101 for the tip. I was running a PHP script to delete fields, one of which is a field collection. By adding a call to field_purge_instance($instance) followed by field_purge_field($field), I was able to delete the field collection w/o hitting this issue that was previously breaking my script.

trianam’s picture

The richshaw101's solution worked for me.
In detail first I used:
field_read_instances(array('deleted' => 1), array('include_deleted' => 1))
for finding the offending field's id (field_id in a record of the returned array) and for getting the instance (the record itself), then i launched:

field_purge_instance($instance);
field_purge_field(field_info_field_by_id($field_id));
David_Rothstein’s picture

Title: Unknown field: field_foo in EntityFieldQuery->addFieldCondition() » Unknown field: field_foo in EntityFieldQuery->addFieldCondition() / other errors when deleted field collection fields are purged
Status: Active » Needs review
FileSize
870 bytes

The problem here seems to be that Field Collection does a lot of things using the field name, but in the case of a deleted field that is now being purged the field name is no longer valid; the existing code does not take this into account.

(You can get even more fun versions of the above bug if you've deleted a field collection field and then created a new field with the same name, but of a different type; that's the situation I found myself in, at any rate.)

The attached patch is sort of a stopgap fix but it might be the best we can easily do. I tried working on a fix for real, and at least part of it involves a change something like this (later on in the same function):

     foreach ($ids as $id_key => $id) {
       $query = new EntityFieldQuery();
       $entities = $query
-        ->fieldCondition($field['field_name'], $field_column, $id)
+        ->fieldCondition($field, $field_column, $id)
         ->execute();
       unset($entities[$entity_type][$entity->$entity_id_name]);

This allows the EntityFieldQuery to correctly use the field record for the deleted field rather than loading an incorrect one, and it does avoid the original error that this issue was filed about. But then new exceptions get thrown a bit later in that function, when entity_delete_multiple() gets called, and I wasn't sure what to do about those. So I went with the stopgap instead.

gdoteof’s picture

delete from field_collection_item where field_name='field_offending_field';

kscheirer’s picture

Priority: Normal » Critical
Issue tags: +D7 stable release blocker

I don't know enough about the codebase to recommend a solution, but this is definitely a critical bug.

webadpro’s picture

I'm running into this issue also. This needs to get fixed asap.

wizonesolutions’s picture

Whoa, this breaks Features too. That's pretty crazy.

When I go to the Features overview page, the following shows up in syslog:

Exception: Invalid field name given: field_template2_popup_fields is not a Field Collection field. in FieldCollectionItemEntity->__construct() (line 210 of sites/all/modules/field_collection/field_collection.module).

Will try running cron.

wizonesolutions’s picture

Had to move away the module directory as others suggested *and* clear the cache twice (drush cc all) before running Cron. After that, moved it back and could get to the Features page.

Took a backup before doing this. Going to try again with the patch this time.

This bug is a special kind of evil. Critical indeed and exacerbated by the inability to disable the module because of the core functionality around pending field deletions.

wizonesolutions’s picture

Never mind. That didn't do it either. Soon as I clear cache again, I'm back where I started.

Trying the query from #10 now.

...Nope, still the same error. Time to try the patch (no need to restore the previous DB dump, it seems...)

wizonesolutions’s picture

Status: Needs review » Needs work

Patch doesn't fix issue. Cron fails with the same message as in #14. Going to try manually emptying the cache tables in the DB and seeing if that helps at all.

wizonesolutions’s picture

This issue seems to be related to if the exported Field Collections are in Features modules or not. It seems like they are pseudo-exportables to some degree and cannot live entirely in code, meaning that they still exist in the DB even after Features are properly reverted. I'm not really clear what's going on here, but I am going to restore my DB backup now and try this process again with the feature in question deleted. If it works there, then that will be good to know.

Supporting info: I manually cleared all the cache tables and deleted references to the field in question in field_config, field_config_instance, andfield_collection_item. The issue persisted, so I knew that it had to be due to the only reference to that field that was left - the Features module containing it.

Extra note before I submitted this comment: I re-enabled the Feature, and the error is back. I'm starting to think this is Features-related. I mean, if it wasn't, wouldn't way more people be having it? I believe there was an issue I saw earlier today that had to do with default fields or something. Once I have debugged a bit into it I'll see what's going on and see if I can find that issue again.

I am leaving the issue properties alone pending testing of the error condition with the module in question disabled.

But if it is confirmed to be with Features, I'm going to set this back to active and downgrade the priority to major. It is unclear how much of this is the fault of Field Collection, how much is the fault of Entity, and how much is the fault of Features.

Does anyone know of any other field modules implemented heavily with Entity that are exportable? Would be good to try to reproduce this error case on a similar module in order to isolate if it was partially Field Collection's fault or not.

wizonesolutions’s picture

Priority: Critical » Major
Status: Needs work » Active

Yep. This is Features's fault. Other than an error about being unable to rename the field table (because of some leftover tables pre-restore), Field Collection field deletion works without a hitch when the Features module containing it is disabled. I can then run Cron and clear the cache without encountering errors.

Time to dive into whatever Features is doing and see if I can extract some meaning from the code flow (the Field API generally scares me, but this was a good warmup).

wizonesolutions’s picture

Found the culprit. It's when the Field Collection on the node has default values. Workaround would probably be to set the default values on the fields *within* the field collection, or to wait until the fields were created to load them, though I am not sure about this yet. I just know that it is the entity_import() call that gets exported with the Features module, meaning that when Features reads the default fields, it calls entity_import(), which obviously bombs since the fields aren't created yet.

This means that responsibility is probably with Field Collection or Entity API indeed.

I think this is a duplicate of another issue, but I have to find that issue, then if I still think it is, I'll mark it as such.

wizonesolutions’s picture

This kind of thing would fail.

/**
 * Implements hook_field_default_fields().
 */
function myfeature_content_types_field_default_fields() {
  $fields = array();

  // Exported field: 'node-template_2-field_template2_popup_fields'.
  $fields['node-template_2-field_template2_popup_fields'] = array(
    'field_config' => array(
      'active' => '1',
      'cardinality' => '10',
      'deleted' => '0',
      'entity_types' => array(),
      'field_name' => 'field_template2_popup_fields',
      'foreign keys' => array(),
      'indexes' => array(),
      'locked' => '0',
      'module' => 'field_collection',
      'settings' => array(
        'hide_blank_items' => TRUE,
        'path' => '',
      ),
      'translatable' => '0',
      'type' => 'field_collection',
    ),
    'field_instance' => array(
      'bundle' => 'template_2',
      'default_value' => array(
        0 => array(
          'entity' => entity_import('field_collection_item', '{
            "item_id" : null,
            "revision_id" : null,
            "field_name" : "field_template2_popup_fields",
            "default_revision" : true,
            "archived" : false,
            "field_popup_title" : { "und" : [] },
            "field_popup_short_text" : { "und" : [] },
            "field_popup_long_text" : { "und" : [] },
            "field_popup_left" : { "und" : [] },
            "field_popup_top" : { "und" : [] },
            "field_popup_width" : { "und" : [] },
            "field_tail_direction" : { "und" : [ { "value" : "bottom" } ] },
            "field_popup_active" : { "und" : [ { "value" : 0 } ] },
            "field_hotspot_height" : { "und" : [] },
            "field_hotspot_left" : { "und" : [] },
            "field_hotspot_top" : { "und" : [] },
            "field_hotspot_width" : { "und" : [] },
            "field_popup_v_pos_type" : { "und" : [ { "value" : "top" } ] },
            "field_show_hotspot" : { "und" : [ { "value" : 0 } ] },
            "field_tail_offset" : { "und" : [] },
            "field_long_text_mode" : { "und" : [ { "value" : 0 } ] }
          }'),
        ),
      ),
      'deleted' => '0',
      'description' => '',
      'display' => array(
        'default' => array(
          'label' => 'above',
          'module' => 'field_collection',
          'settings' => array(
            'add' => 'Add',
            'delete' => 'Delete',
            'description' => TRUE,
            'edit' => 'Edit',
            'view_mode' => 'full',
          ),
          'type' => 'field_collection_view',
          'weight' => 56,
        ),
        'teaser' => array(
          'label' => 'above',
          'settings' => array(),
          'type' => 'hidden',
          'weight' => 0,
        ),
      ),
      'entity_type' => 'node',
      'field_name' => 'field_template2_popup_fields',
      'label' => 'Book Popup Fields',
      'required' => 0,
      'settings' => array(
        'user_register_form' => FALSE,
      ),
      'widget' => array(
        'active' => 0,
        'module' => 'field_collection_table',
        'settings' => array(),
        'type' => 'field_collection_table',
        'weight' => '32',
      ),
    ),
  );
}

If previous posters have time, I'd love if you could grep your Features modules (even just the modulename.field.inc files) for calls to entity_import(). Would be nice to know if this is a solid reproducible case.

wizonesolutions’s picture

OK, I've tracked down the other issues I was looking at before. Unfortunately, they are both marked fixed. But neither of them fixes the underlying problem here, which is that the entity_import() call will fail unless the Field Collection field already exists.

Links:

#1084268: Exception: Invalid field name given. in FieldCollectionItemEntity
#1269750: Exporting a Field Collection field with a default value to Features leads to a PHP parse error

I am going to see if I can find an issue to mark this a duplicate of, and if not, I'll open one and then I'll just work around this (by setting the default_value to NULL) on the site on which I'm encountering this.

wizonesolutions’s picture

OK, some people mentioned this later in #1084268: Exception: Invalid field name given. in FieldCollectionItemEntity, but they were asked to open follow-up issues. They never did. I'm going to go out on a limb and re-categorize this issue *as* the followup. I would not normally do this, but I've already documented it pretty well here, and I am confident this is the cause.

major is the right priority because there is a workaround (edit the Features module's featurename.field.inc file, search for entity_import(, and remove everything between that and the ending ). Make sure to get it all; it spreads over several lines and has a couple nested arrays.

Replace that with NULL so that it looks like:

      'default_value' => NULL,

And then revert the feature (which should show Needs review or Overridden now) so that you don't get this behavior again when you export. If it does not show that, manually go in and blank out all default values on the Field Collection field just to be on the safe side. I haven't tested that though, so I'm just guessing.

This is the workaround. I'm updating the title of this issue, and I will update the issue summary. I don't really need to comment more...I've pretty much documented the bug. It would be great if someone could try to reproduce this. I will put what I believe are the steps to reproduce in the issue summary. But if for some reason I don't (still debugging my Simpletest, which is what got me all the way here), somebody contact me on my contact form and I'll reply with them to you so you can copy them here.

wizonesolutions’s picture

Title: Unknown field: field_foo in EntityFieldQuery->addFieldCondition() / other errors when deleted field collection fields are purged » Setting default values in Content Types -> [content type] -> [field collection field] -> edit causes incorrect Features export
FileSize
80.3 KB

Re-titling.

Suggested solution is twofold:

1) If possible, form_alter away the default values on this screen. There is even already a message that says not to use them (see screenshot).

2) If exporting a field with type field_collection (vs. a field with entity_type field_collection_item), always export a default_value of NULL.

Tests may need to be updated, but I don't think this change would hurt any other contrib modules. It's just removing a meaningless behavior.

DamienMcKenna’s picture

Maybe if Entity API's exportables system wasn't creating full objects it might not be having these problems? *cough* #1864840 *cough*

tim.plunkett’s picture

wizonesolutions’s picture

Ah! It *does* look related! You guys think we should mark it as a duplicate, or just leave this open so people can find the upstream issue more easily? I sort of vote for the latter.

wizonesolutions’s picture

Issue summary: View changes

Added original title. I'm probably going to rename this issue in a comment.

wizonesolutions’s picture

Just realized the other issue is with Rules, so it's not a duplicate. It's just another example.

I think the fix still needs to happen in Field Collection. Updated the issue summary now.

David_Rothstein’s picture

Status: Active » Needs review

@wizonesolutions, can you explain what comments #13 and onward have to do with the original issue that was posted here?

As far as I remember, the original issue had nothing to do with Features; it was just a bug that occurred after deleting a field (regardless of where the field was stored). I believe the patch I posted in #9 fixes that bug.

wizonesolutions’s picture

David: I guess my questions here are:

1. Have you encountered the issue again since and think the patch is still relevant?
2. Was Features installed on the site in question?

I updated the issue just based on how things seemed at the time. Can split it out though if you think it should be changed back.

btopro’s picture

I encounter this issue (related to default not being set I guess) when using field collections in installation profiles:

edit: #22 worked for me. My issue seemed to be related to nested field collections. AFter following the steps in 22 I'm able to install / revert as expected.

mansspams’s picture

Trying to reproduce. Ignore this for a while ;)

I don't understand why all other issues about this bug is closed, since this bug is well and alive even outside Features/Exportables context. I am talking about errors below being thrown while deleting *any* field.

I guess this error happens when field is used both in field_collection and node (reused field). Now I'm not sure should I open new issue or continue here.

    Notice: Undefined property: stdClass::$FIELDNAME_revision_id in field_sql_storage_field_storage_load() (line 360 of C:\Wamp\www\...\modules\field\modules\field_sql_storage\field_sql_storage.module).
    Notice: Undefined property: stdClass::$FIELDNAME_revision_id in field_sql_storage_field_storage_load() (line 360 of C:\Wamp\www\...\modules\field\modules\field_sql_storage\field_sql_storage.module).
    Exception: Invalid field name given: FIELDNAME is not a Field Collection field. in FieldCollectionItemEntity->__construct() (line 211 of C:\Wamp\www\...\sites\all\modules\field_collection\field_collection.module).
steinmb’s picture

Related? Exported ' Hide blank items ' with feature. My feature diff then look kinda strange:

Component: field
        'module' => 'field_collection',
        'settings' => array(
<         'hide_blank_items' => 1,
---
>         'hide_blank_items' => TRUE,
        ),
        'type' => 'field_collection',

Trying to revert the change the change throws a PHP warning.

drush fr my_featuremodule --verbose
Initialized Drupal 7.19 root directory at /drupal
Initialized Drupal site mytest.dev at sites/mytest.dev
Undefined offset: 1 features.drush.inc:607
Do you really want to revert field? (y/n): y
WD features: Reverting my_featuremodule / field.
WD features: Revert completed for my_featuremodule / field.
Reverted field. [OK]
Command dispatch complete

But I'm still overridden.

Workaround

Manually turning off the setting (yes it was turned on) give me the expected result:

Component: field
        'field_name' => 'field_uib_link_section',
        'module' => 'field_collection',
<       'settings' => array(
<         'hide_blank_items' => 1,
<       ),
---
>       'settings' => array(),
        'type' => 'field_collection',
      ),

Turning the setting back on again, unexpectedly get me in a none overridden state. Go figure..

DamienMcKenna’s picture

@steinmb: Did you try doing a features update via Drush to see if it exported the new value? I've found that Features will occasionally export different values when ran via the website versus what's exported via Drush.

btopro’s picture

issue started to pop up again. I don't have entity_insert / the default set to what it was originally. I also took out the hide_blank_items block of settings. Neither matters, can't enable a feature that has field collections in it and once I try to do so I can no longer access the features / modules pages w.o. using drush to disable the feature.

Exception: Invalid field name given: field_sections is not a Field Collection field. in FieldCollectionItemEntity->__construct() (line 210 of field_collection/field_collection.module).

btopro’s picture

So I don't like this kind of solution but if I just comment out the exception it works fine. I'm not sure why we are throwing an exception that something isn't a field collection if the field collection module and exportables are dictating when it is in the system. Seems this can only be thrown if you programatically create a field collection (and incorrectly at that). digging more..

btopro’s picture

As this function already has comments hinting at the fact that it's not complete and is waiting for higher requirements of PHP version by core I don't feel bad posting this "patch" here. This goes a step further then the previous proposed work around and just ignores verification that this is a field_collection. This is an entity type of field_collection which extends entity, if it was defined poorly in code that's a developers problem as far as I'm concerned.

Commenting out this validation check allows for nested field collections to be included in installation profiles as well as the reverting of field collections. If this patch is of use to anyone else it's posted here but I need this so that a feature that contains nested field_collection_items can be activated during an install routine (and d.o. patches can be used in distro packaging).

wizonesolutions’s picture

The Field Collection module is responsible for the code that Features uses to generate the in-code Field Collection. So it's not an end-developer problem. It's a module issue.

You might have meant that, but I wasn't clear. I thought maybe I'd been unclear above. Let me know.

btopro’s picture

I realize it's not a dev problem but seems like that's what this validation check is trying to prevent, someone from programmatically incorporating a field_collection bundle incorrectly. Maybe I'm not seeing it correctly but I'm not really sure what throwing an exception here is helping if commenting it out I'm able to install via Features without issue.

btopro’s picture

In order to package in a distribution I've learned the following from this thread:

Get the latest versions of entity, ctools and field_collection
Check the fields export file for #22 and convert entity_import to NULL as it suggests
Then check for #32 and convert this settings array to an empty array as it suggests
Then push the feature back to your server / attempt to revert / load and it should work just fine.

If you can get it to install / revert on the server then you'll be able to include it in a distribution / install profile.

clevername’s picture

@#4 Removing folder and running cron didn't work for me because this issue was causing cron to be stuck. Instead, I disabled and uninstalled the features module to remove the database references. No more errors.

clevername’s picture

Issue summary: View changes

Redid issue summary.

mrded’s picture

I have similar issue. During feature exporting I cannot manage weight of widgets. They always exports randomly and completely shuffled.
Also when fields were exported - I cannot change labels and required options of them. After "drush -y fu module_name" it always rolls back.

#2281127: Cannot edit field instances

jmuzz’s picture

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

I looked at duplicating this issue by following the steps added to the issue summary in #40 but for as long as I've been using Field Collections it hasn't been possible so set a default value for the field collection fields. The message states:

"To specify a default value, configure it via the regular default value setting of each field that is part of the field collection. To do so, go to the Manage fields screen of the field collection."

So is this still an issue? If so, how can it be duplicated now?

SocialNicheGuru’s picture

this no longer applies to the latest dev version (1-5-15)

jmuzz’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)