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:
- Create a Field Collection field on a content type.
- 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.
- Go back and edit the Field Collection field on the content type. Enter in a default value.
- Install Features 7.x-1.0 if not present.
- Export the Field Collection and its fields in a feature. Save it and put it in
sites/all/modules
.DON'T ENABLE IT YET. - Go back to the content type and delete the Field Collection field.
- 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
Comment | File | Size | Author |
---|---|---|---|
#36 | field_collection-import-fails-1649548-36.patch | 966 bytes | btopro |
#23 | Bildschirmfoto 2013-01-03 um 03.02.36.png | 80.3 KB | wizonesolutions |
#9 | field-collection-skip-deleted-fields-1649548-9.patch | 870 bytes | David_Rothstein |
Comments
Comment #1
fietserwinThe stack trace I get when trying to delete a field collection from a content type:
And more or less the same stack trace when I subsequently run cron:
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.
Comment #2
dynamicdan CreditAttribution: dynamicdan commentedI 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.
Comment #3
michaelfavia CreditAttribution: michaelfavia commentedConfirmed issue as well. I havent debugged it yet but wanted to voice +1 and subscribe. Will post results as i fix it.
Comment #4
sudev.pradhan CreditAttribution: sudev.pradhan commentedIf 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
Comment #5
richshaw101 CreditAttribution: richshaw101 commentedI'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.
Comment #6
osopolarI linked the "post installation" support request (EntityFieldQueryException: Unknown field:) to this ticket.
Comment #7
brettbirschbach CreditAttribution: brettbirschbach commentedThanks 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.
Comment #8
trianam CreditAttribution: trianam commentedThe 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:
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedThe 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):
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.
Comment #10
gdoteof CreditAttribution: gdoteof commenteddelete from field_collection_item where field_name='field_offending_field';
Comment #11
kscheirerI don't know enough about the codebase to recommend a solution, but this is definitely a critical bug.
Comment #12
webadpro CreditAttribution: webadpro commentedI'm running into this issue also. This needs to get fixed asap.
Comment #13
wizonesolutionsWhoa, 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.
Comment #14
wizonesolutionsHad 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.
Comment #15
wizonesolutionsNever 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...)
Comment #16
wizonesolutionsPatch 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.
Comment #17
wizonesolutionsThis 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.
Comment #18
wizonesolutionsYep. 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).
Comment #19
wizonesolutionsFound 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 callsentity_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.
Comment #20
wizonesolutionsThis kind of thing would fail.
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.Comment #21
wizonesolutionsOK, 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.
Comment #22
wizonesolutionsOK, 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'sfeaturename.field.inc
file, search forentity_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:And then revert the feature (which should show
Needs review
orOverridden
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.
Comment #23
wizonesolutionsRe-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_typefield_collection_item
), always export adefault_value
ofNULL
.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.
Comment #24
DamienMcKennaMaybe if Entity API's exportables system wasn't creating full objects it might not be having these problems? *cough* #1864840 *cough*
Comment #25
tim.plunkettThis sounds related to #1269750: Exporting a Field Collection field with a default value to Features leads to a PHP parse error to me, but also #1864840: Change exports to be nested arrays rather than entity_import'd JSON objects as @DamienMcKenna points out.
Comment #26
wizonesolutionsAh! 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.
Comment #26.0
wizonesolutionsAdded original title. I'm probably going to rename this issue in a comment.
Comment #27
wizonesolutionsJust 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.
Comment #28
David_Rothstein CreditAttribution: David_Rothstein commented@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.
Comment #29
wizonesolutionsDavid: 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.
Comment #30
btopro CreditAttribution: btopro commentedI 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.
Comment #31
mansspams CreditAttribution: mansspams commentedTrying 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.Comment #32
steinmb CreditAttribution: steinmb commentedRelated? Exported ' Hide blank items ' with feature. My feature diff then look kinda strange:
Trying to revert the change the change throws a PHP warning.
But I'm still overridden.
Workaround
Manually turning off the setting (yes it was turned on) give me the expected result:
Turning the setting back on again, unexpectedly get me in a none overridden state. Go figure..
Comment #33
DamienMcKenna@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.
Comment #34
btopro CreditAttribution: btopro commentedissue 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).
Comment #35
btopro CreditAttribution: btopro commentedSo 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..
Comment #36
btopro CreditAttribution: btopro commentedAs 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).
Comment #37
wizonesolutionsThe 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.
Comment #38
btopro CreditAttribution: btopro commentedI 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.
Comment #39
btopro CreditAttribution: btopro commentedIn 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.
Comment #40
clevername CreditAttribution: clevername commented@#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.
Comment #40.0
clevername CreditAttribution: clevername commentedRedid issue summary.
Comment #41
mrded CreditAttribution: mrded commentedI 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
Comment #42
jmuzz CreditAttribution: jmuzz commentedI 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?
Comment #43
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedthis no longer applies to the latest dev version (1-5-15)
Comment #44
jmuzz CreditAttribution: jmuzz commented